Re: [BUGS] Missing error message on missing ssl-key-files

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: [BUGS] Missing error message on missing ssl-key-files
Дата
Msg-id 20070130145840.GB20431@svr2.hagander.net
обсуждение исходный текст
Ответ на Re: [BUGS] Missing error message on missing ssl-key-files  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [BUGS] Missing error message on missing ssl-key-files  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, Jan 29, 2007 at 09:56:16PM -0500, Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
> > I'm thinking we need a check in elog.c on the:
> >         if ((!Redirect_stderr || am_syslogger) && pgwin32_is_service())
> >             write_eventlog(edata->elevel, buf.data);
> > line, that checks if the syslogger process has been started yet.
> 
> [ shrug... ]  None of those other variables are guaranteed correct at
> process start, either...

am_syslogger is inialized to "false" by default, so that one is pretty
safe (it' sonly set to true when inside the actual syslogger, which will
of course not happen in the postmaster). And in the syslogger, it's set
at the very top.

Redirect_stderr is initialized to false by default. Which means that
until redirect_stderr is set (=when we read the postgresql.conf file),
the above will alrady evaluate to write to the eventlog (per the
!Redirect_stderr). 

Thus, we only need to cover the time between setting Redirect_stderr to
true (which happens when we read the config file) to starting of the
syslogger.  Looking in postmaster.c, there are several errors that
happen at this point that will use write_stderr, but others (like SSL)
are functoins called that will call elog.

So I think we either need to add this check, or we need to start the
syslogger much sooner. In fact, we need this check anyway, because there
will always be a window between the two where other GUC variables are
set and can cause an error to be logged.

So I still tthink it's a good idea. Even though it doesn't solve every
case, it solves a lot of them I think. And more importantly on that, I
don't see how it would *break* anything (given that it still fires only
when running as a service, when everything on stderr is just thrown away
anyway). Do you see suhc a failure case?

//Magnus


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: stack usage in toast_insert_or_update()
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: 10 weeks to feature freeze (Pending Work)