Re: Proposal: Conflict log history table for Logical Replication

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: vignesh C <vignesh21(at)gmail(dot)com>
Cc: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, shveta malik <shveta(dot)malik(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>
Subject: Re: Proposal: Conflict log history table for Logical Replication
Date: 2026-06-25 11:27:00
Message-ID: CAA4eK1L7tSG6wEErAPd4MGO7yTXd-7fcWG74dgMqQ0Wz2Gw+hQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 25, 2026 at 10:34 AM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Wed, 24 Jun 2026 at 19:27, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> >
>
> 2) jsonb supports indexing, whereas json does not. Was json chosen
> here because inserts are faster due to the lack of parsing and binary
> conversion?
>

I think it is more because the local/remote tuples are usually data
which we want users to see as it was in original tables, using jsonb
can change the ordering of columns or remove some space etc. We can
add a comment on the lines of: "preserve the exact tuple
representation (column order, formatting) for the audit record; the
value is natively json so this avoids a per-conflict conversion". Now,
this is true for tuple data but I am not so sure if the same thing
applies to the replica_identity column in CLT. Would users ever want
to query using ORDER/GROUP BY on replica_identity or use DISTINCT on
it, because if that is possible then the current schema would result
into ERROR as follows:
postgres=# select * from pg_conflict.pg_conflict_log_16394 order by
replica_identity;
ERROR: could not identify an ordering operator for type json

This needs more thoughts from the perspective of how users would like
to fetch the data.

Few other comments:
* errdetail("Conflict log tables are system-managed and only support
cleanup via DELETE or TRUNCATE.")

In the above message 'via' sounds a bit odd, can we instead use
'using' aka "Conflict log tables are system-managed and only support
cleanup using DELETE or TRUNCATE."

2.
@@ -2482,6 +2681,8 @@ DropSubscription(DropSubscriptionStmt *stmt,
bool isTopLevel)
deleteDependencyRecordsFor(SubscriptionRelationId, subid, false);
deleteSharedDependencyRecordsFor(SubscriptionRelationId, subid, 0);

+ drop_sub_conflict_log_table(subid, subname, subconflictlogrelid);

It would be better to drop the table before cleaning up the dependency
record. Right now, it is okay even in current order because dependency
removal is trying to remove where subid is depender.

Apart from above, attached contains a cosmetic/comment improvement patch.

--
With Regards,
Amit Kapila.

Attachment Content-Type Size
v56_amit_1.txt text/plain 1.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message solai v 2026-06-25 11:28:36 Re: Remove the refint contrib module (for v20)
Previous Message Henson Choi 2026-06-25 11:15:20 Re: Key joins