Re: Proposal: Conflict log history table for Logical Replication

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