Re: Proposal: Conflict log history table for Logical Replication

From: shveta malik <shveta(dot)malik(at)gmail(dot)com>
To: Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>
Cc: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, saurabh singh <saurabh(dot)singh214(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Zhijie Hou <houzhijie22(at)gmail(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>
Subject: Re: Proposal: Conflict log history table for Logical Replication
Date: 2026-10-15 10:06:56
Message-ID: CAJpy0uALYDzh4=dSOdar8DOm+E9GPwDxgp-qtyPf_cDQEMsyCA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

A few tirival comments for v81:

v81-001:
1)
insert_conflict_log_tuple:

+ if (TransactionIdIsValid(remote_xid))
+ values[attno++] = TransactionIdGetDatum(remote_xid);
+ else
+ nulls[attno++] = true;

Would it better to replace it with:

/*
* The remote xid is always valid here: a conflict is only detected while
* applying a row change, which is preceded by a BEGIN, BEGIN PREPARE or
* STREAM START that recorded a valid top-level xid.
*/
Assert(TransactionIdIsValid(remote_xid));
values[attno++] = TransactionIdGetDatum(remote_xid);

v81-002:
2)
drop_subscription.sgml:

"If a conflict log table exists for the subscription (that is, when
conflict_log_destination is set to table or all), DROP SUBSCRIPTION
automatically drops the associated conflict log table. In that case,
the subscription cannot be dropped while it has prepared transactions
(see two_phase), because they may hold a lock on the conflict log
table that is released only when the apply worker applies the
corresponding COMMIT PREPARED or ROLLBACK PREPARED. Resolve these
transactions first (see pg_prepared_xacts)."

Above doc seems misleading. It gives an impression that CLT is dropped
while sub can not be dropped in presence of prepared txns.

Should we change it to:
If conflict_log_destination is set to table or all, the subscription
has an associated conflict log table, which DROP SUBSCRIPTION drops
along with the subscription. However, DROP SUBSCRIPTION cannot be
executed while the subscription has prepared transactions (see
two_phase), because such a transaction may hold a lock on the conflict
log table that is released only when the apply worker processes the
corresponding COMMIT PREPARED or ROLLBACK PREPARED. Resolve these
transactions first (see pg_prepared_xacts) before dropping the
subscription.

3)
- "SELECT replica_identity::text FROM $clt_BA WHERE relname = 'tab_temporal';");
-is($clt_row_temporal,
- '{"id":"[1,2)","valid_at":"{[2020-01-01,2021-01-01)}"}',
- 'replica identity uses table column type rather than index opckeytype'
+ "SELECT replica_identity::text FROM $clt_BA WHERE relname = 'tab_temporal';"
);
+is( $clt_row_temporal,
+ '{"id":"[1,2)","valid_at":"{[2020-01-01,2021-01-01)}"}',
+ 'replica identity uses table column type rather than index opckeytype');

Why this change in 002, do we need it?

4)
The test added in 0002 does not cover apply-worker's error in
lock_conflictlog_relation(). Is that intentionally left?

thanks
Shveta

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Japin Li 2026-10-15 10:19:41 Re: Avoid repeated scans of the output buffer in oidvectortypes()
Previous Message Zhijie Hou 2026-10-15 10:01:03 Re: Proposal: Conflict log history table for Logical Replication