Re: Proposal: Conflict log history table for Logical Replication

On Fri, Oct 9, 2026 at 2:51 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Sun, Oct 4, 2026 at 2:01 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> >
> > Here is the failed test case
> >
> > -- On Publisher:
> > CREATE TABLE tab_temporal (
> > id int4range,
> > valid_at datemultirange,
> > PRIMARY KEY (id, valid_at WITHOUT OVERLAPS)
> > );
> > INSERT INTO tab_temporal VALUES ('[1,2)', '{[2020-01-01,2021-01-01)}');
> > CREATE PUBLICATION pub_temporal FOR TABLE tab_temporal;
> >
> > -- On Subscriber:
> > CREATE TABLE tab_temporal (
> > id int4range,
> > valid_at datemultirange,
> > PRIMARY KEY (id, valid_at WITHOUT OVERLAPS)
> > );
> > CREATE SUBSCRIPTION sub_temporal
> > CONNECTION '...'
> > PUBLICATION pub_temporal
> > WITH (conflict_log_destination = 'table');
> >
> > -- After initial sync, delete the row locally on the subscriber:
> > DELETE FROM tab_temporal;
> >
> > -- Then delete the row on the publisher to trigger a
> > delete_missing conflict:
> > DELETE FROM tab_temporal;
> >
> > And without fix shared as a v77-0003 [1], this would error out with
> > below error[2], I have explained the reason [1].
> >
>
> Okay, I see the problem but I wonder why you didn't consider using
> rd_opcintype stored in index relation to solve this problem. I have
> tried the attached atop v79-0001 and v79-0002, manually executed the
> test you shared in this email and it fixed the issue for me.

Yeah you can do that, but if we directly fetch the heap attribute and
then value from the slot like I have done in my 0003 patch you can get
rid of all the processing done inside build_index_datums_from_slot()
i.e. calling FormIndexDatum(BuildIndexInfo) etc. If you see my patch
with that I am able to remove all this extra processing, I am sure we
can get rid of that by some other way as well but I think thats the
most obvious way of doing it.

--
Regards,
Dilip Kumar
Google