Re: [HACKERS] log_destination=file

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: [HACKERS] log_destination=file
Дата
Msg-id CABUevExPGXRk+kjEYrR5omXHZ_Q21b+u+GM3RdRsCZa6d_s1ZA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] log_destination=file  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] log_destination=file  (Dmitry Dolgov <9erthalion6@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Upcoming commit fest will begin soon
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Missing SIZE_MAX