On Tue, Dec 16, 2025 at 11:15 PM Andres Freund <[email protected]> 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
