Re: [HACKERS] log_destination=file - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: [HACKERS] log_destination=file
Date
Msg-id CABUevExPGXRk+kjEYrR5omXHZ_Q21b+u+GM3RdRsCZa6d_s1ZA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] log_destination=file  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] log_destination=file
List pgsql-hackers


On Fri, Sep 1, 2017 at 6:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
> On Fri, Sep 1, 2017 at 6:00 PM, Greg Stark <stark@mit.edu> wrote:
>> So what happens now with these messages? My understanding is that
>> they're missing from the CSV logs and are simply inserted into the
>> text logs without any log_line_prefix? The logging collector doesn't
>> recognize these messages and reformat them for the CSV logs does it?

> Yeah, that's pretty much it.

> Fixing that is also on my plan, but for later :)

Keep in mind that you've got to be really, really conservative about
adding functionality in the logging collector process.  If it ever
crashes, we have problems.  If memory serves, the postmaster is able
to restart it, but we cannot restore the original stdout/stderr
destination, which is problematic if that's where its output had
been going.  So it's pretty close to being as mission-critical as
the postmaster itself.

Yeah. That's one of the reasons I'm not trying to do it all in one batch.

But yeah, the postmaster restarts it just fine. And with the WIP patch I posted earlier, the message from the postmaster that it did gets lost if you are logging to stderr. It does end up in the CSV file though. And I'm sure there are plenty of other corner cases around that one to consider. 

--

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Upcoming commit fest will begin soon
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Missing SIZE_MAX