Re: Proposal: Conflict log history table for Logical Replication

On Sat, Jun 13, 2026 at 4:58 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Sat, Jun 13, 2026 at 3:46 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> >
> > On Thu, Jun 11, 2026 at 5:53 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> > >
> > > On Thu, 11 Jun 2026 at 10:44, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > > >
> > > > Please find the rebased patch
> > > > 1. It includes the new 0005 patch for reporting errors for DDLs on clt.
> > > >
> > > > Open comments:
> > > > 1. Recent comments from Nisha and Shveta after v47 are still open
> > > > 2. Vignesh's patch for "describe related" changes needs a rebase. Can
> > > > you do that, Vignesh? Meanwhile, I will close all the open comments
> > > > and try to share a new version by EOD today.
> > >
> > > Here is the rebased version of the patch attached.
> >
> > Please find attached the latest patch. I have reordered the series,
> > moving 0006 to 0002, and updated the lock restrictions. We now allow
> > ACCESS SHARE mode exclusively to ensure pg_dump can acquire its
> > necessary locks, while blocking higher-level locks to prevent
> > interference with insertions into the conflict log tables.
> >
>
> + /*
> + * Conflict log tables are managed by the system for logical replication
> + * conflicts and should not be locked explicitly. However, AccessShareLock
> + * is allowed to support pg_dump, which must lock tables to prevent them
> + * from being dropped or altered between fetching the table list and
> + * performing the dump. This read-only lock is safe because it does not
> + * interfere with concurrent insertions into the conflict log tables.
> + */
> + if (IsConflictLogTableNamespace(get_rel_namespace(relid)) &&
> + lockmode > AccessShareLock)
> + ereport(ERROR,
> + (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
> + errmsg("permission denied: \"%s\" is a conflict log table",
> + rv->relname),
> + errdetail("Conflict log tables are system-managed and cannot be
> locked explicitly, except in ACCESS SHARE mode.")));
>
> In favor of keeping this code simple, can we allow locking the CLT
> table with the following comment: "Note: Conflict log tables are
> deliberately NOT blocked here, even though other direct DDL on them is
> rejected elsewhere. pg_dump relies on being able to take an ACCESS
> SHARE lock on these tables to safely dump their definitions during
> binary upgrade, so we permit LOCK so we allow LOCK on them and treat
> them like ordinary tables here.
> It's true that a strong lock (ShareLock or above) on such a table
> would conflict with the RowExclusiveLock taken by the apply worker's
> insertsand could stall conflict logging for as long as it is held.

A correction: It would not only stall conflict logging but would also
stall the apply worker (logical replication), or is there a default
lock timeout that I am not aware of? If there's no such timeout, we
can correct the comment slightly.

thanks
Shveta