Re: Add jsonlog log_destination for JSON server logs

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Add jsonlog log_destination for JSON server logs
Дата
Msg-id YgW66yQdmXX17VQs@paquier.xyz
обсуждение исходный текст
Ответ на Re: Add jsonlog log_destination for JSON server logs  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
On Thu, Feb 10, 2022 at 07:45:17PM -0300, Alvaro Herrera wrote:
> From what I hear in the container world, what they would *prefer* (but
> they don't often get) is to receive the JSON-format logs directly in
> stderr from the daemons they run; they capture stderr and they have the
> logs just in the format they need, without having to open the log files,
> parsing the lines to rewrite in a different format as is done currently.

Yes, I have been pinged about that, which is why there are still cases
for my out-of-core extension jsonlog that uses the elog hook.

> I think this would be a relatively easy patch to do.  Opinions?

The postmaster goes through a couple of loops with the fd to open for
the default format, that the syslogger inherits from the postmaster,
and I am pretty sure that there are a couple of code paths around the
postmaster startup that can be tricky to reason about.

Making the new parameter PGC_POSTMASTER makes things easier to handle,
still the postmaster generates a couple of LOG entries and redirects
them to stderr before loading any GUC values, which would mean that we
cannot make sure that all the logs are valid JSON objects.  If we want
to be 100% waterproof here, we may want to track down the format to
use by default with a mean different than a GUC for the postmaster
startup?  A file holding this information in the root of the data
folder would be one way.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Add jsonlog log_destination for JSON server logs
Следующее
От: Andres Freund
Дата:
Сообщение: Re: generic plans and "initial" pruning