Re: Finer grain log timestamps

From: Isaac Morland <isaac(dot)morland(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, David Fetter <david(at)fetter(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Finer grain log timestamps
Date: 2022-06-20 17:19:05
Message-ID: CAMsGm5deymN4CKGWp75LySPPQz28Nvkwef-yeW_W4xC7OgmGHA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 20 Jun 2022 at 11:01, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2022-06-20 17:29:57 CFM for 2022-07
Previous Message Robert Haas 2022-06-20 16:21:47 Re: SLRUs in the main buffer pool, redux