Re: Replication slot WAL reservation

> On Mar 25, 2025, at 09:56, Phillip Diffley <phillip6402(at)gmail(dot)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.