On Tue, Sep 23, 2025 at 11:29 PM Masahiko Sawada <[email protected]> wrote: > > On Sat, Sep 20, 2025 at 4:59 AM Amit Kapila <[email protected]> wrote: > > > > > AFAIR, one open point for internally created tables is whether we > > should skip changes to conflict_history table while replicating > > changes? The table will be considered under for ALL TABLES > > publications, if defined? Ideally, these should behave as catalog > > tables, so one option is to mark them as 'user_catalog_table', or the > > other option is we have some hard-code checks during replication. The > > first option has the advantage that it won't write additional WAL for > > these tables which is otherwise required under wal_level=logical. What > > other options do we have? > > I think conflict history information is subscriber local information > so doesn't have to be replicated to another subscriber. Also it could > be problematic in cross-major-version replication cases if we break > the compatibility of history table definition. >
Right, this is another reason not to replicate it. > I would expect that the > history table works as a catalog table in terms of logical > decoding/replication. It would probably make sense to reuse the > user_catalog_table option for that purpose. If we have a history table > for each subscription that wants to record the conflict history (I > believe so), it would be hard to go with the second option (having > hard-code checks). > Agreed. Let's wait and see what Dilip or others have to say on this. -- With Regards, Amit Kapila.
