From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: "Not safe to send CSV data" message |
Date: | 2009-11-19 03:38:37 |
Message-ID: | 3952.1258601917@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> And the fact that it comes out at all suggests that
>> the csvlog startup logic is rather broken. Comments?
> Not sure why you say that. This can only happen very early in the
> startup process before the postmaster has had a chance to finish setting
> up the syslogger process and dup the pipes. As soon as that happens
> redirection_done is set to true and this message is no longer possible.
Well, in that case the code is operating as designed and the bleating is
simply inappropriate. What I was wondering was whether we should try to
launch the syslogger before we do process_shared_preload_libraries().
But now that I think about it, I think that ordering was intentional
on the grounds that some types of monitoring plugins might want to be
live in all postmaster children including the syslogger. In any case
there will certainly always be *some* postmaster messages that could
be emitted after setting the log_destination GUC and before launching
the syslogger child. If the designed behavior is that we dump to
stderr during that interval, we should just do it, without the useless
and confusing bleating.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-11-19 03:43:58 | Re: Listen / Notify - what to do when the queue is full |
Previous Message | Andrew Chernow | 2009-11-19 03:32:14 | Re: Listen / Notify - what to do when the queue is full |