Re: Improve pg_sync_replication_slots() to wait for primary to advance - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: Improve pg_sync_replication_slots() to wait for primary to advance
Date
Msg-id CAExHW5uU+a7OYF3iVF5VDW01UCGNwqi2nWxf933Bc5=To8iMUQ@mail.gmail.com
Whole thread Raw
In response to Re: Improve pg_sync_replication_slots() to wait for primary to advance  (Ashutosh Sharma <ashu.coek88@gmail.com>)
List pgsql-hackers
On Sat, Sep 6, 2025 at 12:05 AM Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
>
> On Fri, Sep 5, 2025 at 6:52 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
> >
> > On Wed, Sep 3, 2025 at 11:58 AM Ajin Cherian <itsajin@gmail.com> wrote:
> > >
> > > I've tested this and I see that interrupts are being handled by
> > > sending SIGQUIT and SIGINT to the backend process.
> >
> > Can you please point me to the code (the call to
> > CHECK_FOR_INTERRUPTS()) which processes these interrupts while
> > pg_sync_replication_slots() is executing, especially when the function
> > is waiting while syncing a slot.
> >
>
> I noticed that the function libpqrcv_processTuples, which is invoked
> by fetch_remote_slots, includes a CHECK_FOR_INTERRUPTS call. This is
> currently helping in processing interrupts while we are in an infinite
> loop within SyncReplicationSlots(). I’m just pointing this out based
> on my observation while reviewing the changes in this patch. Ajin,
> please correct me if I’m mistaken. If not, can we always rely on this
> particular check for interrupts.

It doesn't seem good to rely on CHECKF_FOR_INTERRUPTS from so far
away. It's better to have one being called from SyncReplicationSlots()
which has the wait loop. That's how the other functions which have
potentially long wait loops do.

--
Best Wishes,
Ashutosh Bapat



pgsql-hackers by date:

Previous
From: Alyona Vinter
Date:
Subject: Re: Resetting recovery target parameters in pg_createsubscriber
Next
From: Ashutosh Bapat
Date:
Subject: Re: Improve pg_sync_replication_slots() to wait for primary to advance