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

From: Osama Abdul Qader <osamaabdulqaderpostgres(at)gmail(dot)com>
To: Zhijie Hou <houzhijie22(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Subject: Re: Avoid using raw xmin of frozen tuples in logicalrep conflict detection
Date: 2026-11-09 11:42:40
Message-ID: CAAprpiB-i_tOf-QKQ7FGZbQ_GW2jVNk=T1HV15iPRUyAiLZ=fg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Mon, 9 Nov, 2026, 5:05 pm Zhijie Hou, <houzhijie22(at)gmail(dot)com> wrote:

> Hi,
>
> On Fri, Nov 6, 2026 at 12:13 PM Zhijie Hou wrote:
> > Hi Andres,
> >
> > On Wed, Nov 4, 2026 at 09:33 PM Andres Freund wrote:
> > > That surely is not the right fix, it breaks any sense of abstraction
> > > across table AMs. There's afaict no guarantee that the target table
> > > is heapam. And even if there currently is, we shouldn't bake that in
> > > further.
> >
> > Thanks for pointing it out. I agree that conflict.c shouldn't be
> > reaching into BufferHeapTupleTableSlot or HeapTupleHeaderGetXmin()
> > directly.
> >
> > To avoid that, on master, it seems cleanest to handle this at the
> > TupleTableSlotOps level (alongside getsysattr and
> > is_current_xact_tuple in execTuples.c), for example, via an optional
> > callback that returns the effective xmin (HeapTupleHeaderGetXmin() for
> > heap/buffer-heap slots, and InvalidTransactionId when NULL for
> > virtual/minimal slots or AMs that don't store tuple xmin).
> >
> > TransactionId (*get_effective_xmin) (TupleTableSlot *slot);
>
> Following this, I am attaching two patches implementing the approaches
> discussed above for reference:
>
> v2-0001-Fix-logical-xx.patch adds an optional get_effective_xmin
> callback to TupleTableSlotOps (alongside getsysattr and
> is_current_xact_tuple). Heap and buffer-heap slots implement it via
> HeapTupleHeaderGetXmin(), while slots that do not provide this
> information leave the callback unset so slot_get_effective_xmin()
> returns InvalidTransactionId.
>
> nocfbot-v2-0001-Fix-logical-xx.patch avoids adding a new
> TupleTableSlotOps callback (which is also needed for back-patching to
> 18) by checking TTS_IS_BUFFERTUPLE(localslot) ||
> TTS_IS_HEAPTUPLE(localslot) in GetTupleTransactionInfo() to use
> HeapTupleHeaderGetXmin(), and falling back to slot_getsysattr() for
> other slot types.
>
> What do you think ?
>
> --
> Best Regards,
> Zhijie Hou

I'm open to review the new patches, I'll reply again after reviewing it,
not only that I'm also open to fix the issues that comes after reviewing
it.

I regret for the inconvenience I caused earlier, I assure to everyone here
that this won't happen again.

With Regards,
Osama Abdul Qader.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Srinath Reddy Sadipiralla 2026-11-09 11:43:49 Re: Standby stuck after walreceiver restart just before a WAL segment boundary
Previous Message Zhijie Hou 2026-11-09 11:34:41 Re: Avoid using raw xmin of frozen tuples in logicalrep conflict detection