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: Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, vignesh C <vignesh21(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>, shveta malik <shvetamalik(at)gmail(dot)com>
Subject: Re: Proposal: Conflict log history table for Logical Replication
Date: 2026-06-02 07:41:33
Message-ID: CAHut+PsxJFv5zXRo6-ZFFw4UUpWQUyv23FQTRain-4jAEajyjw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joel Jacobson 2026-06-02 07:55:45 Re: PostgreSQL 19 Beta 1 release announcement draft
Previous Message Hayato Kuroda (Fujitsu) 2026-06-02 07:32:59 RE: pg_createsubscriber: allow duplicate publication names