| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Peter Smith <smithpb2250(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Replace is_publishable_class() with relispublishable column in pg_class |
| Date: | 2025-12-18 10:40:33 |
| Message-ID: | CAA4eK1LNjWigHb5YKz2nBwcGQr18WnNZHv3Gyo8GNCshSkAb-A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Dec 17, 2025 at 5:53 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Wed, Dec 17, 2025 at 12:37 PM Peter Smith <smithpb2250(at)gmail(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2025-12-18 11:06:15 | Re: Proposal: Conflict log history table for Logical Replication |
| Previous Message | Alexander Korotkov | 2025-12-18 10:38:43 | Re: Implement waiting for wal lsn replay: reloaded |