Re: Logical Replication - behavior of TRUNCATE ... CASCADE - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Logical Replication - behavior of TRUNCATE ... CASCADE
Date
Msg-id CAFiTN-t7j=uUdAnU9DJPW4k=0OFWn51g5m=g3Sexs7JRRAKPaA@mail.gmail.com
Whole thread Raw
In response to Re: Logical Replication - behavior of TRUNCATE ... CASCADE  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Logical Replication - behavior of TRUNCATE ... CASCADE
List pgsql-hackers
On Mon, May 3, 2021 at 6:08 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.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



pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Identify missing publications from publisher while create/alter subscription.
Next
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: batch fdw insert bug (Postgres 14)