On Tue, Dec 16, 2025 at 11:15 PM Andres Freund <andres@anarazel.de> wrote:
>
> 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?
Yeah we can do that, in fact the current patch already does that. The
problem is the conflict log tables are created as regular tables and
in order to identify whether any table is used as a conflict log table
we need to scan the pg_subscription. So in order to simplify this it
seems the table level property could be a better idea considering the
comments atop is_publishable_class() which says "the long-term
solution is to add a boolean
column to pg_class and depend on that instead of OID checks.".
Another motivation I am seeing is that we can extend this solution to
the SQL level syntax whether users can create tables by marking that
as non-publishable so that even when publication is created with ALL
TABLE options such tables can be excluded.
> 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.
--
Regards,
Dilip Kumar
Google
