Re: Replace is_publishable_class() with relispublishable column in pg_class

On Wed, Dec 17, 2025 at 9:52 AM Andres Freund <andres@anarazel.de> wrote:
>
> On 2025-12-17 09:19:57 +0530, Dilip Kumar wrote:
> > On Tue, Dec 16, 2025 at 11:15 PM Andres Freund <andres@anarazel.de> wrote:
> > > 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?
> >
> > Not sure I completely got this point,  but let me explain the
> > requirement, so the idea is that the conflict log table which are
> > created for the subscription if the conflict log table option is set
> > then all the conflict occurred on the node would be inserted into this
> > table, so you can consider this as a log which we want to use for
> > better lookup instead of looking into the server logs.  So IMHO this
> > table stores very node specific conflict information which might not
> > make any sense for other nodes.
>
> Imagine you have a bi-directional replication setup between A <-> B. Then you
> want to upgrade A to a new major version A'. To minimize downtime, you want to
> use logical replication for that. For the logical replication A -> A', you
> *would* want to logically replicate the conflict log table, because the
> history of logical conflicts is actually important.
>

Yes, we need it for this case but still we need a way to distinguish
cases where we won't need to send conflict table changes for FOR ALL
TABLES publication (say a bi-directional replication set up). For
cases where user wants to allow conflict table changes to be
replicated, we want users to explicitly mention conflict_table in a
publication either as a publication option or explicitly as part of
FOR TABLE syntax, otherwise, its changes won't be replicated. So, to
ignore changes for other publications like FOR ALL TABLES, such a flag
(relispublishable) could be useful. The other way to identify whether
to replicate the changes in conflict table is as mentioned by Dilip
that for the first time when replicating a change for a table, we need
to scan pg_subscription to identify whether the current table is a
conflict log table and then cache it as relsync cache entry. We need
to do this because the conflict table is created as a regular table
along with subscriptions. Do you have any better ideas?

--
With Regards,
Amit Kapila.