Horton
Menu

Re: Proposal: Conflict log history table for Logical Replication

Peter Smith <smithpb2250@gmail.com>

View thread
From: Peter Smith <smithpb2250@gmail.com>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Nisha Moond <nisha.moond412@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, vignesh C <vignesh21@gmail.com>, shveta malik <shveta.malik@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, shveta malik <shvetamalik@gmail.com>
Date: 2026-06-02T07:41:33Z
Lists: pgsql-hackers 
Hi Dilip.

I've been thinking more about this new option:
conflict_log_destination (enum) = 'log' or 'table' or 'all'.

I think it behaves more like a bitmap than an enum. Also, having 'all'
as an enum value seems odd to me. IMO, this new option is actually
more similar to the 'publish' option from CREATE PUBLICATION.

I suggest it might be better to implement this as a *string* option:
conflict_log_destination (string), and has allowed values of 'log' and 'table'.

e.g.
conflict_log_destination = 'log'
conflict_log_destination = 'table'
conflict_log_destination = 'log, table'

Apart from being more intuitive and readable, this way is also
future-proof in case some 3rd/4th/etc way of logging is invented --
e.g. the user can define whatever combinations they want instead of
being stuck with only "all".

Thoughts?

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

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