Re: Replace is_publishable_class() with relispublishable column in pg_class

From: Andres Freund <andres(at)anarazel(dot)de>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Subject: Re: Replace is_publishable_class() with relispublishable column in pg_class
Date: 2025-12-16 17:45:17
Message-ID: fpepoh22dwjlnhn6v7f5ksicxqmtxy6scvfqkjrrcdjytmn2hk@chy5pcp26ln4
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2025-12-16 11:28:11 -0500, Andres Freund wrote:
> On 2025-12-16 21:19:21 +0530, Dilip Kumar wrote:
> > 2) As suggested by Amit Kpila [2], for the upcoming Conflict Log Table
> > feature, we need a clean way to exclude these internal conflict log
> > tables from publication. A catalog flag allows us to set this property
> > at relation creation rather than adding more special cases.
>
> Seems like the issue here also could be addressed the same way?

Actually, wouldn't a table-level property be completely inappropriate for
that? Imagine one publication that's used for HA (or major version upgrade)
and doesn't use a conflict table, which replicates all tables (including the
conflict table of another pub/sub). And a subscription doing bi-direction
replication that *does* obviously use the conflict table. In one of those
cases you want to replicate changes to the conflict table, in the other
not. So a table / pg_class property would be inappropriate, no?

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christoph Berg 2025-12-16 17:54:46 Re: failed NUMA pages inquiry status: Operation not permitted
Previous Message Jacob Champion 2025-12-16 17:40:44 Re: [oauth] Stabilize the libpq-oauth ABI (and allow alternative implementations?)