On Wed, Dec 17, 2025 at 5:53 PM Amit Kapila <[email protected]> wrote: > > On Wed, Dec 17, 2025 at 12:37 PM Peter Smith <[email protected]> wrote: > > > > Here is a completely different idea. This may solve the immediate > > problem re the replication of the Conflict Log Table (CLT) at least... > > > > Another idea could be that at the startup (pgoutput_startup), we can > form a conflict_table cache and then use it to determine whether to > send the change or not? Along with that we need to consider whether > publication explicitly indicates that a conflict_table changes needs > to be replicated or not. >
Yet another idea to cache catalog table information to avoid look up overhead is to declare unique_index on dbid+cat_relid similar to existing index SubscriptionNameIndexId. Then after the first time looking up the entry for the catalog table, keep a corresponding flag in the RelSyncCache table entry. -- With Regards, Amit Kapila.
