Re: Replication slot WAL reservation

> On Mar 25, 2025, at 09:56, Phillip Diffley <phillip6402@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
assignedto 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
monotonicallyincreasing (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
tobe "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
thatis involved in that transaction (and any other WAL that might be between operations for that transaction), unless
youare 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'tabsolutely bet on it never doing so.