On Tue, Jan 30, 2007 at 10:32:14AM -0500, Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
> > 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?
>
> The case I'm worried about is subprocess startup, where we haven't yet
> been able to re-set any of these variables correctly. And yes, I think
> it's an issue: if a DBA is expecting to find PG error messages in the
> syslogger files, he's unlikely to go look in the eventlog.
But in that case, the syslogger is already running, right? So it'll pick
up the messages and drop them in the log as expected. Because we can't
start backends before the syslogger is up, and I think it's the first of
our subprocesses to start still?
You'll have problems if the syslogger keeps crashing, but if that
happens we will at least have the log that the syslogger is crashing.
I get the feeling I'm missing something, but I'm not sure what it is :-)
But I guess maybe the added check has to be not just (!syslogger_started)
but (!syslogger_started && is_postmaster)?
//Magnus
