Re: BUG #19549: Physical replication slot xmin value stuck
Re: BUG #19549: Physical replication slot xmin value stuck
От:
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Дата:
Hi, On Thu, Jul 9, 2026 at 3:04 AM PG Bug reporting form wrote: > > The following bug has been logged on the website: > > Bug reference: 19549 > Logged by: nitin mangnale > Email address: nmangnale2@gmail.com > PostgreSQL version: Unsupported/Unknown > Operating system: Linux (ubuntu 22.04 LTS) > Description: > > Hello PostgreSQL Community, > > I am looking for assistance in investigating what appears to be an unusual > replication/xmin behavior on PostgreSQL 13.20. PostgreSQL 13 reached end of life in November 2025 [1]. The community no longer provides bug fixes or investigates issues for EOL versions, so getting help here will be difficult. If possible, I would recommend upgrading to a supported version and checking if the issue still reproduces there. [1] https://www.postgresql.org/support/versioning/ > Problem Description > > One of our standby servers periodically causes a physical replication slot > on the primary to retain a very old "xmin". The "age(xmin)" continuously > increases over time, preventing vacuum from advancing normally on the > primary. > > The unusual part is that we cannot identify any backend or query responsible > for holding the snapshot. > > The issue only affects one standby. The second standby remains healthy. > > Restarting the affected standby immediately clears the problem, but after > several days the same behavior returns. Thanks for reporting this. > Observed Behavior > > On the primary: > > slot_name : oseu2012766 > slot_type : physical > active : true > xmin : 788928341 > age(xmin) : 5419501 (continuously increasing) > restart_lsn : 1835DD/EB000000 Did you check on the standby if there is any backend holding xmin = 788928341 or closer somewhere? > Questions > > 1. Is this a known issue or edge case in PostgreSQL 13.20 involving physical > replication slots or hot_standby_feedback? > > 2. Is it expected for "pg_replication_slots.xmin" to remain pinned while > "pg_stat_replication.backend_xmin" is NULL? Yes. Check the docs [2]. The field backend_xmin shows the standby's xmin horizon reported by hot_standby_feedback. This field will be null if a replication slot is used (in that case, the standby's xmin is shown in pg_replication_slots). So in your case, this is expected. [2] https://www.postgresql.org/docs/devel/monitoring-stats.html#MONITORING-PG-STAT-REPLICATION-VIEW > 3. Are there any known bugs in PostgreSQL 13.x related to stale standby > feedback or snapshot lifecycle that match this behavior? Without a reproducer or additional details or extensive checks on the standby, it is hard to treat this as a bug. > 4. Are there any additional internal views, debugging techniques, or GUC > parameters that would help identify the source of the pinned xmin? Maybe it is worth looking at what the standby reports as xmins via hot_standby_feedback [3] and whether it matches what is being reported in the primary's pg_replication_slots.xmin. [3] https://github.com/postgres/postgres/blob/REL_13_STABLE/src/backend/replication/walreceiver.c#L1252 > 5. Would upgrading to a newer PostgreSQL major version be expected to > resolve this behavior if it is related to snapshot or hot standby feedback > handling? Without understanding the issue and query patterns on the standby, it is hard to say. However, since PostgreSQL 13 is no longer supported by the community, upgrading to a newer version in a sandboxed environment and testing whether the issue recurs would be a reasonable next step. > At this point we are considering rebuilding the affected standby, but we > would like to understand the root cause before doing so. Why do you think rebuilding the standby would resolve the issue? -- Bharath Rupireddy Amazon Web Services: https://aws.amazon.com
RE: Follow-up review items for update_deleted
От:
"Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Дата:
On Monday, September 7, 2026 2:37 PM Amit Kapila wrote: > On Fri, Sep 4, 2026 at 3:27 PM Zhijie Hou (Fujitsu) > wrote: > I have made minor changes in the comments to make them clear. See > attached. > > > > > > > Both 4 and 5 are documented but will it be better to provide this > > > information explicitly, say via Logging when the conflcit_slot is > > > not getting advanced due to any of these reasons? > > > > We can do that. It seems to me we could make this improvement for PG20 > > at this stage. For PG19, I think we can improve the documentation to > > make it a bit clearer instead. Amit and I discussed this off-list, and > > See 0002 for the patch Amit shared to improve the doc. > > Thanks for sharing the doc updates. Can you please fold those in 0001 and > share a combined patch? Thanks for the changes. I've merged them, here is the updated patch. I confirmed that the patch applies cleanly on PG19 as well. Best Regards, Zhijie Hou
