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