On Thursday, December 18, 2025 7:40 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Dec 17, 2025 at 3:58 PM Zhijie Hou (Fujitsu)
> <houzj.fnst@fujitsu.com> wrote:
> >
> > Here is a small patch to fix it.
> >
>
> Thanks, I've pushed the patch. BTW, looking at the code of slot_sync API code
> path, I could think of the following improvements.
>
> *
> if (remote_slot->confirmed_lsn > latestFlushPtr)
> { update_slotsync_skip_stats(SS_SKIP_WAL_NOT_FLUSHED);
>
> /*
> * Can get here only if GUC 'synchronized_standby_slots' on the
> * primary server was not configured correctly.
> */
> ereport(AmLogicalSlotSyncWorkerProcess() ? LOG : ERROR,
> errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
>
> Can we change this ERROR to LOG even for API as now the API also retires to
> sync the slots during initial sync?
>
> * The use of the slot_persistence_pending flag in the internal APIs seems to
> be the reverse of what it should be. I mean to say that initially it should be
> true and when we actually persist the slot then we can set it to false.
>
> * We can retry to sync all the slots present in the primary at the start of API,
> not only temporary slots. If we do this then the previous point may not be
> required. Also, please mention something
> like: "It retries cyclically until all the failover slots that existed on primary at
> the start of the function call are synchronized." in the function description [1]
> as well.
Here is the patch to address these points. The patch improves the function to
retry for both slots that fail to persist and those persistent slots that have
skipped subsequent synchronizations.
Best Regards,
Hou zj
