On Sat, Jun 13, 2026 at 4:58 PM Amit Kapila <[email protected]> wrote: > > On Sat, Jun 13, 2026 at 3:46 PM Dilip Kumar <[email protected]> wrote: > > > > On Thu, Jun 11, 2026 at 5:53 PM vignesh C <[email protected]> wrote: > > > > > > On Thu, 11 Jun 2026 at 10:44, Dilip Kumar <[email protected]> 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
