Re: Proposal: Conflict log history table for Logical Replication

shveta malik <shveta.malik@gmail.com>

From: shveta malik <shveta.malik@gmail.com>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, vignesh C <vignesh21@gmail.com>, Nisha Moond <nisha.moond412@gmail.com>, Peter Smith <smithpb2250@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, shveta malik <shveta.malik@gmail.com>
Date: 2026-06-11T10:34:13Z
Lists: pgsql-hackers
On Thu, Jun 11, 2026 at 10:44 AM Dilip Kumar <dilipbalaut@gmail.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.
>

Thanks. A few comments:

1)
If I rename pg_conflict schema; apply worker handles it well as I do
not see any issue, but pg_dump starts giving problem:.

 ./pg_dump -d postgres  -p 5434 > sub.log
pg_dump: error: query failed: ERROR:  permission denied:
"pg_conflict_log_16390" is a conflict log table
DETAIL:  Conflict log tables are managed by the system for logical replication.
pg_dump: detail: Query was: LOCK TABLE public.tab1,
conflict_new.pg_conflict_log_16390 IN ACCESS SHARE MODE

Can dependency on name be removed even from pg_dump to avoid above issue?

2)
+ /*
+ * Conflict log tables are used internally for logical replication conflict
+ * logging and should not be modified directly, as it could disrupt
+ * conflict logging.
+ */
+ if (IsConflictLogTableClass(classform))
+ ereport(ERROR,
+ (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
+ errmsg("permission denied: \"%s\" is a conflict log table",
+ rv->relname),
+ errdetail("Conflict log tables are managed by the system for logical
replication.")));

The comment is too generic. Suggestion:

/*
 * Disallow extended statistics on conflict log tables. These are
 * internal, system-managed tables with no indexes, making
 * statistics useless for planning while adding unnecessary
 * catalog dependency overhead.
 */

3)
If we want to keep one generic DETAIL msg, shall it be changed to:

Conflict log tables are system-managed tables for logical replication conflicts.
~~

Will review more tomorrow.

thanks
Shveta



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Allow logical replication conflicts to be logged to a table.

  2. Avoid orphaned objects dependencies