> On Mar 25, 2025, at 09:56, Phillip Diffley <phillip6...@gmail.com> wrote:
> 1. Every DML operation (insert, update, delete, truncate) will have a row in
> the WAL and that row will have an LSN assigned to it.
> 2. The LSNs are assigned when the operation happens.
> 3. Operations within a transaction are written to the WAL in a contiguous
> block when the transaction commits.
> 4. Each transaction block in the WAL has a commit timestamp associated with
> it, and these timestamps are monotonically increasing (I'm only inferring
> this, so please correct me if this is not always the case).
This isn't *quite* right. LSNs are byte offsets, not operation sequence
numbers (despite the name), so they don't have to be "assigned"; they're just
an offset to a particular point in the (virtual) WAL bytestream.
The WAL is written as it is generated (allowing for buffering etc.). A
transaction end flushes out any remaining WAL that is involved in that
transaction (and any other WAL that might be between operations for that
transaction), unless you are not in synchronous_commit mode.
It's not quite the "transaction block" that has the commit timestamp; it's the
commit record for a particular transaction. I can't come up with a scenario
off the top of my head in which the commit timestamp would go down, but I
wouldn't absolutely bet on it never doing so.
