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

On Fri, Sep 25, 2009 at 05:18, Robert Haas <robertmhaas@gmail.com> wrote:
> 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?

I've never heard of that, so I'd be very interested in hearing if somebody did.

Actually, it's not starting the logging collector that's the issue.
It's the redirection.

So we could always start the logging collector, but not necessarily
redirect stderr. For those who then set logging to "file", it gets
passed to the logging collector. Those who set it to "stderr" just
have to deal with stderr somehow (pg_ctl -l for example). It's still
going to require a restart to change stderr, but that will only hit
those people who are actually having performance issues from it  (and
want to switch to using stderr instead of logging collector).

Then we just send the data to the syslogger over a separate pipe. If
we keep the "endpoint" of this pipe in the postmaster, a new syslogger
could just "pick that up" after a crash, no? Data that goes on stderr
will still go to stderr and not be captured in this case, but normally
that would be no data at all, and if it did happen it'd be caught by
wherever you point pg_ctl -l at (which is the same place the early
startup messages goes, before the logger is running).



-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/