agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Reset conflict slot's xmin when a subscription (re)starts retent 2+ messages / 1 participants [nested] [flat]
* pgsql: Reset conflict slot's xmin when a subscription (re)starts retent @ 2026-09-07 09:24 Amit Kapila <akapila@postgresql.org> 0 siblings, 0 replies; 2+ messages in thread From: Amit Kapila @ 2026-09-07 09:24 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Reset conflict slot's xmin when a subscription (re)starts retention. Since the retain_dead_tuples feature uses a single cluster-wide replication slot across all subscriptions, adding a new subscription on a database with an older active transaction can require conflict_detection_slot.xmin to move backward to avoid missing dead tuples needed for update_deleted conflict detection. Previously, if a newly created subscription had an older active transaction than the slot's current xmin, the slot update occurred during worker apply, leading to an assertion failure. Fix this by having the launcher track the set of databases with active tuple-retaining subscriptions. When a database joins this set (either via a new subscription or when retention restarts), the launcher resets the slot's xmin to the cluster-wide safe decoding horizon before starting any workers. Because this horizon accounts for all active transactions across the entire cluster, it serves as a safe seed without requiring retroactive backward movement by individual apply workers. In passing, update the retain_dead_tuples documentation to clarify two operational boundary cases: (a) Conflict data continues to accumulate even when a subscription is disabled or its apply worker is stopped. (b) track_commit_timestamp must be enabled for conflict detection to function properly. Reported-by: Nisha Moond <nisha.moond412@gmail.com> Author: Zhijie Hou <houzj.fnst@fujitsu.com> Author: Amit Kapila <amit.kapila16@gmail.com> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Reviewed-by: Nisha Moond <nisha.moond412@gmail.com> Reviewed-by: shveta malik <shveta.malik@gmail.com> Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com> Discussion: https://postgr.es/m/TY4PR01MB177182F547A62FC2666EC04EC94B72@TY4PR01MB17718.jpnprd01.prod.outlook.com Backpatch-through: 19, where it was introduced Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/6168c65ddcac4494fb292418cc774897791e0667 Modified Files -------------- doc/src/sgml/ref/create_subscription.sgml | 31 +++++- src/backend/replication/logical/launcher.c | 173 ++++++++++++++++++++--------- src/test/subscription/t/035_conflicts.pl | 73 ++++++++++++ 3 files changed, 221 insertions(+), 56 deletions(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
* pgsql: Reset conflict slot's xmin when a subscription (re)starts retent @ 2026-09-07 09:24 Amit Kapila <akapila@postgresql.org> 0 siblings, 0 replies; 2+ messages in thread From: Amit Kapila @ 2026-09-07 09:24 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Reset conflict slot's xmin when a subscription (re)starts retention. Since the retain_dead_tuples feature uses a single cluster-wide replication slot across all subscriptions, adding a new subscription on a database with an older active transaction can require conflict_detection_slot.xmin to move backward to avoid missing dead tuples needed for update_deleted conflict detection. Previously, if a newly created subscription had an older active transaction than the slot's current xmin, the slot update occurred during worker apply, leading to an assertion failure. Fix this by having the launcher track the set of databases with active tuple-retaining subscriptions. When a database joins this set (either via a new subscription or when retention restarts), the launcher resets the slot's xmin to the cluster-wide safe decoding horizon before starting any workers. Because this horizon accounts for all active transactions across the entire cluster, it serves as a safe seed without requiring retroactive backward movement by individual apply workers. In passing, update the retain_dead_tuples documentation to clarify two operational boundary cases: (a) Conflict data continues to accumulate even when a subscription is disabled or its apply worker is stopped. (b) track_commit_timestamp must be enabled for conflict detection to function properly. Reported-by: Nisha Moond <nisha.moond412@gmail.com> Author: Zhijie Hou <houzj.fnst@fujitsu.com> Author: Amit Kapila <amit.kapila16@gmail.com> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Reviewed-by: Nisha Moond <nisha.moond412@gmail.com> Reviewed-by: shveta malik <shveta.malik@gmail.com> Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com> Discussion: https://postgr.es/m/TY4PR01MB177182F547A62FC2666EC04EC94B72@TY4PR01MB17718.jpnprd01.prod.outlook.com Backpatch-through: 19, where it was introduced Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9186ffd6336763b9f38fee25b32f3e556b4ca518 Modified Files -------------- doc/src/sgml/ref/create_subscription.sgml | 31 +++++- src/backend/replication/logical/launcher.c | 173 ++++++++++++++++++++--------- src/test/subscription/t/035_conflicts.pl | 73 ++++++++++++ 3 files changed, 221 insertions(+), 56 deletions(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-09-07 09:24 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-09-07 09:24 pgsql: Reset conflict slot's xmin when a subscription (re)starts retent Amit Kapila <akapila@postgresql.org> 2026-09-07 09:24 pgsql: Reset conflict slot's xmin when a subscription (re)starts retent Amit Kapila <akapila@postgresql.org>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox