Re: Finer grain log timestamps - Mailing list pgsql-hackers

From Isaac Morland
Subject Re: Finer grain log timestamps
Date
Msg-id CAMsGm5deymN4CKGWp75LySPPQz28Nvkwef-yeW_W4xC7OgmGHA@mail.gmail.com
Whole thread Raw
In response to Re: Finer grain log timestamps  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Finer grain log timestamps  (Jacob Champion <jchampion@timescale.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: SLRUs in the main buffer pool, redux
Next
From: Jacob Champion
Date:
Subject: CFM for 2022-07