Re: Proposal: Conflict log history table for Logical Replication

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, shveta malik <shveta(dot)malik(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>
Subject: Re: Proposal: Conflict log history table for Logical Replication
Date: 2026-01-27 03:08:54
Message-ID: CAHut+PuaqNDfDu_3xkZR4OYxw-B7ew_WjpLXCBvMcSBJz2K6Xg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Dilip.

Some comments for the first 2 patches:

//////////
v24-00001
//////////

1.
+ /*
+ * Conflict log tables are managed by the system to record logical
+ * replication conflicts. We do not allow locking rows in CONFLICT
+ * relations.
+ */
+ if (IsConflictNamespace(RelationGetNamespace(rel)))
+ ereport(ERROR,
+ (errcode(ERRCODE_WRONG_OBJECT_TYPE),
+ errmsg("cannot lock rows in CONFLICT relation \"%s\"",
+ RelationGetRelationName(rel))));

AFAIK, this "CONFLICT relation" terminology is not used anywhere else.

Why not just call it what it is:

e.g.
cannot lock rows in conflict log table \"%s\"

~

OTOH, if you were attempting to future-proof the message for different
kinds of relations in the 'pg_conflict' namespace, I still felt it
might be better to refer to 'pg_conflict' instead of CONFLICT:

e.g.
cannot lock rows in 'pg_conflict' relation \"%s\"

//////////
v24-0002
//////////

1.
+static char *build_index_value_desc(EState *estate, Relation localrel,
+ TupleTableSlot *slot, Oid indexoid);

Declared twice?

======
Kind Regards,
Peter Smith.
Fujitsu Australia.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2026-01-27 03:12:35 Re: Remove PG_MMAP_FLAGS
Previous Message Amit Langote 2026-01-27 03:00:13 Re: Batching in executor