On Fri, Feb 13, 2026 at 7:54 AM Zhijie Hou (Fujitsu)
<[email protected]> wrote:
>
> Thanks for pushing! Here are the remaining patches.
>
One thing that bothers me about the remaining patch is that it could
lead to infinite re-tires in the worst case. For example, in first
try, slot-1 is not synced say due to physical replication delays in
flushing WALs up to the confirmed_flush_lsn of that slot, then in next
(re-)try, the same thing happened for slot-2, then in next (re-)try,
slot-3 appears to invalidated on standby but it is valid on primary,
and so on. What do you think?
Independent of whether we consider the entire patch, the following bit
in the patch in useful as we retry to sync the slots via API.
@@ -218,7 +219,7 @@ update_local_synced_slot(RemoteSlot *remote_slot,
Oid remote_dbid)
* Can get here only if GUC 'synchronized_standby_slots' on the
* primary server was not configured correctly.
*/
- ereport(AmLogicalSlotSyncWorkerProcess() ? LOG : ERROR,
+ ereport(LOG,
errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("skipping slot synchronization because the received slot sync"
" LSN %X/%08X for slot \"%s\" is ahead of the standby position %X/%08X",
--
With Regards,
Amit Kapila.
