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

From Magnus Hagander
Subject Re: WIP - syslogger infrastructure changes
Date
Msg-id 9837222c0909260850x48c6b7fdl9b2343910f9f8ac@mail.gmail.com
Whole thread Raw
In response to Re: WIP - syslogger infrastructure changes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Sep 26, 2009 at 17:43, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Sep 25, 2009 at 5:22 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> AIUI the problem is that when logging_collector is on, we throw away
>>> the original stderr.  That's OK as long as you never try to switch
>>> back to it.
>
>> BTW, this seems like it could be fixed with some appropriate file
>> descriptor management in postmaster.  No?
>
> Yeah, probably.  In the current system design it didn't seem to be
> necessary because collecting the collector process's own stderr output
> is usually not all that critical.  If we had the postmaster dup its
> original stderr and the collector dup it back, that would be a more
> complete but more complex solution.  (dup2 works on Windows, no?)

Yeah, they should.

Not sure how that works through process boundaries though, we do some
special fiddling for any handles that need to be inherited.

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: WIP - syslogger infrastructure changes
Next
From: Tom Lane
Date:
Subject: Re: TODO item: Allow more complex user/database default GUC settings