Re: Proposal: Conflict log history table for Logical Replication

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, shveta malik <shvetamalik(at)gmail(dot)com>
Subject: Re: Proposal: Conflict log history table for Logical Replication
Date: 2026-05-29 09:22:58
Message-ID: CAFiTN-t04zWHek+LuB5uF1hY9+6B-x_nuL8AhwHkFCYv64iOaA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 28, 2026 at 2:57 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Wed, May 27, 2026 at 1:34 AM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> >
> > On Tue, 26 May 2026 at 15:08, shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> > >
> > > On Mon, May 25, 2026 at 10:13 AM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> > > >
> > > >
> > > > Thanks for the comments, the attached v39 version patch has the
> > > > changes for the same.
> > > >
> > >
> > > I have not yet looked at v40, but please find a few ocmments on
> > > v39-0001 and 0002 merged together.
> > > 4)
> > > Do we need to have CommandCounterIncrement() after
> > > heap_create_with_catalog() in create_conflict_log_table()? I think
> > > even if we are not doing any table_open etc for CLT in same
> > > transaction, we should call CommandCounterIncrement() (to be
> > > consistent with other such calls of heap_create_with_catalog and to
> > > make it future proof). Thoughts?
> >
> > I felt this is not required as we are not doing a table open on the
> > newly created table.
> >
>
> Okay, command counter increment would be required here if we further
> access that relation in the same command.

I think CommandCounterIncrement() is called wherever we need to open
the relation in the same command. In this particular case we do not
need to open the conflict log table so we do not need to call CCI

I think I am facing a
> related problem w.r.t newly created subscription. After applying first
> six patches, the create subscription fails as follows:
> postgres=# create subscription sub1 connection 'dbname=postgres'
> publication pub1 with (conflict_log_destination='all');
> ERROR: dependent subscription was concurrently dropped
>
> I debugged and found that we get the above ERROR when we are trying to
> find the subscription which is not yet created. In this case, it seems
> to be happening because we are using a subscription that is yet not
> created for dependency recording. This raises a question as to why are
> we creating the conflict_log_table before subscription, at least this
> needs some comments.

This error occurs because in the commit below [1], we disallowed
recording a dependency on an object that does not exist. Therefore, we
now need to record the dependency after the subscription is created.
And we create CLT before so that we can add the conflict log relid in
pg_subscription without an additional update, I will add a comment
explaining this.

[1]
commit 2fbb21170e9053720c2c374b21eb650a22b8aaea
Author: Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>
Date: Wed May 27 18:35:58 2026 +0300
Avoid orphaned objects dependencies

--
Regards,
Dilip Kumar
Google

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Henson Choi 2026-05-29 09:41:52 Re: Row pattern recognition
Previous Message Amit Langote 2026-05-29 08:56:51 Re: generic plans and "initial" pruning