Skip site navigation (1) Skip section navigation (2)

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

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Harald Armin Massa <haraldarminmassa(at)gmail(dot)com>,PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [BUGS] Missing error message on missing ssl-key-files
Date: 2007-01-30 14:58:40
Message-ID: 20070130145840.GB20431@svr2.hagander.net (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
On Mon, Jan 29, 2007 at 09:56:16PM -0500, Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Adriaan van OsDate: 2007-01-30 15:10:07
Subject: Re: [HACKERS] [BUGS] BUG #2907: pg_get_serial_sequence quoting
Previous:From: Tom LaneDate: 2007-01-30 14:51:16
Subject: Re: stack usage in toast_insert_or_update()

pgsql-bugs by date

Next:From: Adriaan van OsDate: 2007-01-30 15:10:07
Subject: Re: [HACKERS] [BUGS] BUG #2907: pg_get_serial_sequence quoting
Previous:From: Yosef HaasDate: 2007-01-30 14:44:19
Subject: now() in PL/pgSQL Functions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group