Re: Proposal: Conflict log history table for Logical Replication

From: shveta malik <shveta(dot)malik(at)gmail(dot)com>
To: vignesh C <vignesh21(at)gmail(dot)com>
Cc: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(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 <shveta(dot)malik(at)gmail(dot)com>
Subject: Re: Proposal: Conflict log history table for Logical Replication
Date: 2026-01-06 03:21:10
Message-ID: CAJpy0uB_Kj4XTHB41pMM8WtMRDwMAx3tXi=nDowrd9MSrH8UNw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I was checking patch006. I understand the purpose of patch 006, but I
don’t think it’s needed at the moment. Currently, we support only two
destinations: log and table, and we already provide 'all' to cover
both. This patch would make sense if we either supported at least
three destinations or didn’t have the 'all' option. As it stands, none
of the comma-separated combinations are meaningful:

log,all
table,all
log,table (already covered by all)

Should we defer this patch until we actually support additional
destinations? One option is to remove 'all', but for now, 'all' feels
more appropriate than introducing comma-separated values.

thanks
Shveta

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-01-06 03:27:29 Re: Typos in the code and README
Previous Message Fujii Masao 2026-01-06 03:02:34 Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect