Horton

Re: Improve pg_sync_replication_slots() to wait for primary to advance

Dilip Kumar <dilipbalaut@gmail.com>

View thread
From: Dilip Kumar <dilipbalaut@gmail.com>
To: shveta malik <shveta.malik@gmail.com>
Cc: Ajin Cherian <itsajin@gmail.com>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2025-07-18T06:01:04Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Enhance slot synchronization API to respect promotion signal.

  2. Fix inconsistent elevel in pg_sync_replication_slots() retry logic.

  3. Refactor slot synchronization logic in slotsync.c.

  4. Fix intermittent BF failure in 040_standby_failover_slots_sync.

  5. Add retry logic to pg_sync_replication_slots().

  6. Fix LOCK_TIMEOUT handling in slotsync worker.

  7. Add slotsync skip statistics.

On Fri, Jul 18, 2025 at 11:25 AM shveta malik <shveta.malik@gmail.com> wrote:
>
> Okay.  I see your point. Yes, it was non-blocking earlier but it was
> not giving ERROR, it was just dumping in logilfe that primary is
> behind and thus slot-sync could not be done.
>
> If we continue using the non-blocking mode, there’s a risk that the
> API may never successfully sync the slots. This is because it
> eventually drops the temporary slot on exit, and when it tries to
> create a new one later on subsequent call, it’s likely that the new
> slot will again be ahead of the primary. This may happen if we have
> continuous ongoing writes on the primary and the logical slot is not
> being consumed at the same pace.
>
> My preference would be to avoid including such an option as it is
> confusing. With such an option in place, users may think that
> slot-sync is completed while that may not be the case.

Fair enough

 But if it's
> necessary for backward compatibility, it should be okay to provide it
> as a non-default option as you suggested. Would like to know what
> others think of this.

I think we don't need to maintain backward compatibility here as it
was not behaving sanely before, so I am fine with providing the
behaviour we are doing with the patch.

-- 
Regards,
Dilip Kumar
Google