Re: WIP - syslogger infrastructure changes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP - syslogger infrastructure changes
Date
Msg-id 20196.1252959278@sss.pgh.pa.us
Whole thread Raw
In response to WIP - syslogger infrastructure changes  (Magnus Hagander <magnus@hagander.net>)
Responses Re: WIP - syslogger infrastructure changes
List pgsql-hackers
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.

> ... 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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: generic copy options
Next
From: Jaime Casanova
Date:
Subject: Re: new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)