Re: Avoid using raw xmin of frozen tuples in logicalrep conflict detection

Hi,

On Wed, Nov 4, 2026 at 9:17 PM Osama Abdul Qader
<osamaabdulqaderpostgres(at)gmail(dot)com> 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