Re: Finer grain log timestamps

Поиск
Список
Период
Сортировка
От Isaac Morland
Тема Re: Finer grain log timestamps
Дата
Msg-id CAMsGm5deymN4CKGWp75LySPPQz28Nvkwef-yeW_W4xC7OgmGHA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Finer grain log timestamps  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Finer grain log timestamps  (Jacob Champion <jchampion@timescale.com>)
Список pgsql-hackers
On Mon, 20 Jun 2022 at 11:01, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
 
If I were coding it, I would allow only exactly 1 digit (%.Nt) to simplify
the parsing side of things and bound the required buffer size.  Without
having written it, it's not clear to me whether further restricting the
set of supported values would save much code.  I will point out, though,
that throwing an error during log_line_prefix processing will lead
straight to infinite recursion.

I would parse the log_line_prefix when it is set. Then if there is a problem you just log it using whatever format is in effect and don't change the setting. Then the worst that happens is that logs show up in a format log processing isn't prepared to accept.

That being said, I think I fall in the “just start putting more digits in the log” camp, although it is conceivable the counter arguments might be convincing.

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: SLRUs in the main buffer pool, redux
Следующее
От: Jacob Champion
Дата:
Сообщение: CFM for 2022-07