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

Hi Zhijie,

On Wed, 4 Nov, 2026, 7:00 pm Zhijie Hou, <houzhijie22(at)gmail(dot)com> wrote:

> 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
>
Thank you for clearing my concerns.

> Please refer to the tests added in the patch for the reproduction steps.

Sure, I'll refer to the test added in the patch, and also I'll review it,
though my schedule is a bit tight, but sure I'll do it.

With Regards,
Osama Abdul Qader.

>