Hi, On Sat, Nov 14, 2026 at 09:04:57AM +0530, Amit Kapila wrote: > On Fri, Nov 13, 2026 at 7:29 PM Bertrand Drouvot > <[email protected]> wrote: > > > > On Fri, Nov 13, 2026 at 04:45:00PM +0530, Amit Kapila wrote: > > > > > > + else if (slot->data.persistency == RS_TEMPORARY) > > > + { > > > + /* > > > + * We reach this point when a previous cycle updated confirmed_flush > > > + * but failed to build a consistent snapshot, and the remote slot has > > > + * not advanced beyond the local slot since then. > > > + */ > > > + skip_reason = SS_SKIP_NO_CONSISTENT_SNAPSHOT; > > > + } > > > > > > Is it better to directly use the slot's skip_reason rather than > > > assuming SS_SKIP_NO_CONSISTENT_SNAPSHOT? > > > > That could work but what about the case I mentioned upthread where the local > > catalog_xmin gets ahead and the remote later catches up? I think that that > > would > > keep slotsync_skip_reason as SS_SKIP_WAL_OR_ROWS_REMOVED, although the slot > > is > > still inconsistent due to the missing snapshot. > > > > Right the reason can remain as SS_SKIP_WAL_OR_ROWS_REMOVED. Even in > the first cycle, the reason could be either SS_SKIP_WAL_NOT_FLUSHED or > SS_SKIP_WAL_OR_ROWS_REMOVED and in that case also the caller
Oh right, I missed SS_SKIP_WAL_NOT_FLUSHED. > update_and_persist_local_synced_slot() won't persist the slot. So, I > don't see a problem with retaining the previous reason when we didn't > perform anything in a particular sync cycle. Right, but once the WAL has been flushed or the remote slot has caught up, retaining SS_SKIP_WAL_NOT_FLUSHED or SS_SKIP_WAL_OR_ROWS_REMOVED would make slotsync_skip_reason report a misleading reason: the slot remains temporary because it still has no consistent snapshot. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
