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

Hi

On Sun, 8 Nov, 2026, 11:41 am Zhijie Hou, <houzhijie22(at)gmail(dot)com> wrote:

> Hi,
>
> On Sun, Nov 8, 2026 at 12:29 AM Osama Abdul Qader wrote:
> >
> > One possible approach for master would be to extend TupleTableSlotOps
> with
> > a callback such as:
> >
> > `TransactionId (*get_effective_xmin) (TupleTableSlot *slot);`
> ...
> > What do you think about introducing get_effective_xmin as a slot
> operation
> > for master?
>
> I'm afraid I find your reply quite confusing, as it is repeating the
> proposal
> I already made in my reply to Andres, without any difference I can see.
>
> Could you please read the discussion in this thread carefully and
> share your thoughts after considering it? If you're using AI to help
> draft replies, please review and understand the output fully before
> sending it.
>
> --
> Best Regards,
> Zhijie Hou
>

Thank you for pointing this out, I repeat the proposal of
get_effective_xmin callback approach, I apologize for the confusion I
caused here.

I'd be interested in helping with the implementation and further
investigation of this approach. In particular, I can examine the callback's
behavior across the different TupleTableSlotOps implementations, identify
any edge cases around frozen tuples and invalid transaction IDs, and work
on regression tests.

I'd also like to understand the compatibility constraints for the backpatch
branches and how the proposed master implementation should differ from them.

If useful, I'd be happy to take on this implementation work and submit a
patch for review.

Best regards,
Osama Abdul Qader.