On Monday, July 28, 2025, Bruce Momjian <
bruce@momjian.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.
