Hi, On Wed, Nov 4, 2026 at 9:17 PM Osama Abdul Qader <[email protected]> wrote: > > 1. Why did GetTupleTransactionInfo() use slot_getsysattr() originally? Was it > chosen to avoid full tuple conversion/detoasting overhead via > ExecFetchSlotHeapTuple(), and what is the performance trade-off of changing > it?
There is no performance difference here. The tuple in the slot is already a buffer heap tuple in this path, so passing it directly adds no conversion cost. I missed to handle the frozen case when writing the original codes. > 2. How is a "normal transaction ID" strictly defined here? Does the check use > TransactionIdIsNormal() to filter out frozen, bootstrap, and > bootstrap/subtransaction placeholder XIDs? Yes, TransactionIdIsNormal() conveniently filters out the frozen XID here. The other cases you mention shouldn't occur in this path anyway, since we're detecting conflicts on user table changes. > 3. How can this bug be reliably reproduced in an automated regression test? > Is it possible to artificially freeze a tuple via vacuum or pg_freeze/SQL > commands and trigger a logical replication conflict deterministically, or > does it require specific timing with XID wraparound? Please refer to the tests added in the patch for the reproduction steps. -- Best Regards, Zhijie Hou
