From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Daniel Bauman <danielbaniel(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Doc update proposal for the note on log_statement in the runtime config for logging page |
Date: | 2025-07-29 14:19:13 |
Message-ID: | aIjYYWELVkKPe7YS@momjian.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jul 28, 2025 at 07:35:51PM -0400, Bruce Momjian wrote:
> On Mon, Jul 28, 2025 at 04:24:14PM -0700, Daniel Bauman wrote:
> > Here's where I think the logging is happening. https://github.com/postgres/
> > postgres/blob/master/src/backend/tcop/postgres.c#L1070
> > It seems like the log is happening before application of the transaction, not
> > after.
> >
> > So consistency is best effort. ie - a crash after the log but before the
> > transaction is committed could result in a logged statement that wasn't
> > actually committed.
> >
> > Logging is not handled in the WAL and is not guaranteed to be consistent in the
> > way that different statements in a transaction are, which is the nuance that
> > I'm interested in documenting.
> > Maybe the doc update should be to say that statements in the log may not have
> > been applied rather than saying that applied statements might not appear in the
> > log.
>
> Yes, right, it is not that we do some "best effort", whatever that
> means, but rather we just log when we start running the statement. The
> docs clearly explain we log after parsing but before execution:
>
> Statements that contain simple syntax errors are not logged even
> by the <varname>log_statement</varname> = <literal>all</literal>
> setting, because the log message is emitted only after basic
> parsing has been done to determine the statement type.
"log_min_duration_statement=0" might be closer to what you want since it
is only printed when the query completes.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-07-29 14:37:41 | Re: Making pgfdw_report_error statically analyzable |
Previous Message | Pavel Stehule | 2025-07-29 14:18:42 | Re: event trigger support for PL/Python |