Re: Logical Replication - behavior of TRUNCATE ... CASCADE

On Mon, May 3, 2021 at 6:08 PM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> Having said that, isn't it good if we can provide a subscription
> (CREATE/ALTER) level option say "cascade"(similar to other options
> such as binary, synchronous_commit, stream) default being false, when
> set to true, we send upstream CASCADE option to ExecuteTruncateGuts in
> apply_handle_truncate? It will be useful to truncate all the dependent
> tables in the subscriber. Users will have to use it with caution
> though.

I think this could be a useful feature in some cases. Suppose
subscriber has some table that is dependent on the subscribed table,
in such case if the main table gets truncated it will always error out
in subscriber, which is fine. But if user doesn’t want error and he
is fine even if the dependent table gets truncated so I feel there
should be some option to set that. I think the documentation should
clearly say the impact of setting this to true.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com