Re: Replication slot WAL reservation - Mailing list pgsql-general

From Christophe Pettus
Subject Re: Replication slot WAL reservation
Date
Msg-id 8760F666-DF81-4BEA-9CA9-80BBC569210E@thebuild.com
Whole thread Raw
In response to Replication slot WAL reservation  (Phillip Diffley <phillip6402@gmail.com>)
List pgsql-general

> 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. 


pgsql-general by date:

Previous
From: Phillip Diffley
Date:
Subject: Replication slot WAL reservation
Next
From: Tom Lane
Date:
Subject: Re: How to pass a list of locations (longitude, latitude) to a PostgreSQL/PostGIS stored function?