On Mon, Sep 14, 2009 at 4:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> First, the patch removes the logging_collector parameter and basically
>> assumes that logging_collector is always on.
>
> I don't find that to be a good idea, and you certainly have not made
> a case why we should change it. I can't see any reason why pushing
> functionality out of backends and downstream to the syslogger process
> is an improvement. What it's more likely to do is create a processing
> bottleneck and a single point of failure.
Hmm. I think the justification was supposed to be this part here:
$ With that, it's no longer necessary to restart your server just to
$ reconfigure the logging, and it also takes away a confusing parameter
$ (really "log_destination=stderr, logging_collector=on" is *not* a logical
$ way to say "log to file"). Instead, it adds a log_destination of "file" that
$ is the standard log to file."
Do we have any positive or negative experience with logging_collector
as a performance bottleneck? Are there people running with
logging_collector=off to avert disaster?
>> ... Given that the syslogger is now
>> always started, those that actually *want* logging to stderr (which I
>> claim is a low number of people, but that's a different story) will
>> have it go through the syslogger and then to the stderr of syslogger.
>
> That design doesn't work because there is then *no* way to recover from
> a syslogger crash. You no longer have access to the original stderr
> file once the postmaster has redirected stderr to syslogger. We can
> live with that so long as syslogger's stderr output isn't very
> interesting, but not if it's going to be the main log channel.
I haven't read the patch yet, but this seems like it might be
surmountable by having the postmaster keep both file descriptors
around, and letting the children make appropriate calls to dup2() and
close() just after forking.
...Robert