Re: Proposal: Conflict log history table for Logical Replication
| От | Alastair Turner |
|---|---|
| Тема | Re: Proposal: Conflict log history table for Logical Replication |
| Дата | |
| Msg-id | CAC0GmyyHfdWvY6CO74k=F4KjTyNOoR-2iftkhiW5LWzZuFkBzA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Proposal: Conflict log history table for Logical Replication (Dilip Kumar <dilipbalaut@gmail.com>) |
| Ответы |
Re: Proposal: Conflict log history table for Logical Replication
|
| Список | pgsql-hackers |
Hi Dilip
Thanks for working on this, I think it will make conflict detection a lot more useful.
On Sat, 6 Sept 2025, 10:38 Dilip Kumar, <dilipbalaut@gmail.com> wrote:
While working on the patch, I see there are some open questions
1. We decided to pass the conflict history table name during
subscription creation. And it makes sense to create this table when
the CREATE SUBSCRIPTION command is executed. A potential concern is
that the subscription owner will also own this table, having full
control over it, including the ability to drop or alter its schema.
...
Typed tables and the dependency framework can address this concern. The schema of a typed table cannot be changed. If the subscription is marked as a dependency of the log table, the table cannot be dropped while the subscription exists.
2. A further challenge is how to exclude these tables from publishing
changes. If we support a subscription-level log history table and the
user publishes ALL TABLES, the output plugin uses
is_publishable_relation() to check if a table is publishable. However,
applying the same logic here would require checking each subscription
on the node to see if the table is designated as a conflict log
history table for any subscription, which could be costly.
Checking the type of a table and/or whether a subscription object depends on it in a certain way would be a far less costly operation to add to is_publishable_relation()
3. And one last thing is about should we consider dropping this table
when we drop the subscription, I think this makes sense as we are
internally creating it while creating the subscription.
Having to clean up the log table explicitly is likely to annoy users far less than having the conflict data destroyed as a side effect of another operation. I would strongly suggest leaving the table in place when the subscription is dropped.
Regards
Alastair
В списке pgsql-hackers по дате отправления: