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.
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 |