Re: Proposal: Conflict log history table for Logical Replication

Amit Kapila <amit.kapila16@gmail.com>

From: Amit Kapila <amit.kapila16@gmail.com>
To: Peter Smith <smithpb2250@gmail.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>, Nisha Moond <nisha.moond412@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-02T10:52:30Z
Lists: pgsql-hackers
On Tue, Jun 2, 2026 at 1:12 PM Peter Smith <smithpb2250@gmail.com> wrote:
>
> 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".
>

I think if we support other formats where conflict logs can be stored
then 'all' will be more relevant as instead of typing all the formats
individually users can use 'all'. Also, we should be able to extend
this option to multi-value if required in future, so the current
proposal seems reasonable to me.

-- 
With Regards,
Amit Kapila.



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