On Fri, Sep 12, 2025 at 1:07 PM Ashutosh Sharma <[email protected]> wrote: > > On Mon, Sep 8, 2025 at 9:52 AM Ashutosh Sharma <[email protected]> wrote: > > > > I think we can do that, since sync_skip_reason appears to be a > > descriptive metadata rather than statistical data like > > slot_sync_skip_count and last_slot_sync_skip. However, it's also true > > that all three pieces of data are transient by nature - they will just > > be present in the runtime. > > > > After spending some more time on this, I found that maintaining > sync_skip_reason in pg_replication_slots would make the code changes a > bit messy and harder to maintain. >
What exactly is your worry? It seems more logical to have sync_skip_reason in pg_replication_slots and other two in pg_stat_replication_slots as the latter is purely a stats view and the sync_skip_count/last_sync_skip suits there better. I think storing all 3 pieces of > information - sync_skip_reason, sync_skip_count, and last_sync_skip in > pg_stat_replication_slots would be a cleaner solution. This way, all > the sync-related info stays together and the code remains > straightforward. > Having all the sync information together has merit but don't you think in this case the sync_skip_reason doesn't seem to be matching with the existing columns in pg_stat_replication_slots? -- With Regards, Amit Kapila.
