Re: Persist slot invalidations before publishing them - Mailing list pgsql-hackers

From Bertrand Drouvot
Subject Re: Persist slot invalidations before publishing them
Date
Msg-id arP4wN5HW8h0Sr90@bdtpg
Whole thread
In response to Re: Persist slot invalidations before publishing them  (shveta malik <shveta.malik@gmail.com>)
Responses Re: Persist slot invalidations before publishing them
List pgsql-hackers
Hi,

On Wed, Sep 23, 2026 at 04:07:02PM +0530, shveta malik wrote:
> Can we create the helper function for this logic as it is not core to
> the sync-function. Please use the attached patch if you agree, and
> feel free to change comments as you see apt.

I was initially a bit skeptical about adding a helper with only one caller, as it
seemed to just move the PG_TRY() block elsewhere without reducing duplication.

On second thought, I agree it makes sense here, as it keeps the lock acquisition
and required ERROR cleanup ordering together. There are also similar "one caller"
helpers wrapping PG_TRY() blocks, such as start_table_sync() and start_sequence_sync().

+static void
+persist_slot_invalidation(ReplicationSlot *slot, ReplicationSlotInvalidationCause cause)
+{

I changed it slightly to derive slot from MyReplicationSlot, ensuring that the I/O
lock belongs to the same slot that ReplicationSlotPersistInvalidation() and
and ReplicationSlotRelease() are using. This is also consistent with other operations
on the currently acquired slot.

Please find v5 attached.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

Attachment

pgsql-hackers by date:

Previous
From: Florents Tselai
Date:
Subject: Re: add list of major features to the v19 release notes
Next
From: Nurlan Tulemisov
Date:
Subject: Re: Import Statistics in postgres_fdw before resorting to sampling.