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, <[email protected]> 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
