Re: Proposal: Conflict log history table for Logical Replication
От | Dilip Kumar |
---|---|
Тема | Re: Proposal: Conflict log history table for Logical Replication |
Дата | |
Msg-id | CAFiTN-v=amzGth4QSsoFk6E_2L09HNmxwDze8n-12g=pB_=ZZA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal: Conflict log history table for Logical Replication (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Proposal: Conflict log history table for Logical Replication
|
Список | pgsql-hackers |
On Wed, Sep 24, 2025 at 4:00 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Tue, Sep 23, 2025 at 11:29 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > On Sat, Sep 20, 2025 at 4:59 AM Amit Kapila <amit.kapila16@gmail.com> 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. Yeah I think this makes sense to create as 'user_catalog_table' tables when we internally create them. However, IMHO when a user provides its own table, I believe we should not enforce the restriction for that table to be created as a 'user_catalog_table' table, or do you think we should enforce that property? -- Regards, Dilip Kumar Google
В списке pgsql-hackers по дате отправления: