On Thu, 28 Aug 2025 at 14:56, Amit Kapila <[email protected]> wrote: > > On Thu, Aug 28, 2025 at 11:07 AM Ashutosh Sharma <[email protected]> > wrote: > > > > We have seen cases where slot synchronization gets delayed, for example > > when the slot is behind the failover standby or vice versa, and the slot > > sync worker has to wait for one to catch up with the other. During this > > waiting period, users querying pg_replication_slots can only see whether > > the slot has been synchronized or not. If it has already synchronized, > > that’s fine, but if synchronization is taking longer, users would naturally > > want to understand the reason for the delay. > > > > Is there a way for end users to know the cause of slot synchronization > > delays, so they can take appropriate actions to speed it up? > > > > I understand that server logs are emitted in such cases, but logs are not > > something end users would want to check regularly. Moreover, since logging > > is configuration-based, relevant messages may sometimes be skipped or > > suppressed. > > > > Currently, the way to see the reason for sync skip is LOGs but I think > it is better to add a new column like sync_skip_reason in > pg_replication_slots. This can show the reasons like > standby_LSN_ahead_remote_LSN. I think ideally users can compare > standby's slot LSN/XMIN with remote_slot being synced. Do you have any > better ideas? >
How about something like pg_stat_progress_replication_slot with remote LSN/standby LSN/catalog XID etc? Wouldn't this be in sync with all other debug pg_stat_progress* views and thus more Postgres-y? -- Best regards, Kirill Reshke
