Re: Replace is_publishable_class() with relispublishable column in pg_class
| От | Amit Kapila |
|---|---|
| Тема | Re: Replace is_publishable_class() with relispublishable column in pg_class |
| Дата | |
| Msg-id | CAA4eK1LNjWigHb5YKz2nBwcGQr18WnNZHv3Gyo8GNCshSkAb-A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Replace is_publishable_class() with relispublishable column in pg_class (Amit Kapila <amit.kapila16@gmail.com>) |
| Список | pgsql-hackers |
On Wed, Dec 17, 2025 at 5:53 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Wed, Dec 17, 2025 at 12:37 PM Peter Smith <smithpb2250@gmail.com> 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.
В списке pgsql-hackers по дате отправления: