Re: Doc update proposal for the note on log_statement in the runtime config for logging page

On Monday, July 28, 2025, Bruce Momjian <bruce(at)momjian(dot)us> 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.

Your invalid assumption that commit/transaction is at all relevant here is
not something we’ve induced.

A select query returns the results to a client regardless of whether the
transaction it is executed within is committed or rolled back. Not logging
such a query because the transaction was rolled back would be an insane
design choice.

The only true “best-effort” consideration would be if somehow the logging
itself was flaky, say under system load, such that attempted writes to disk
somehow never made it there. I suppose in the case of a crash and “sync”
patterns there may be a latent bug or active design choice to not let those
syncs bog down the system…but that hasn’t been shown and I wouldn’t expect
it to exist absent such documentation. It’s definitely not correct to call
what we have best-effort. It’s just normal logging of valid statements
presented for execution. A normal type of audit trail of what work the
system performed.

David J.