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

Поиск
Список
Период
Сортировка
От Dilip Kumar
Тема Re: Logical Replication - behavior of TRUNCATE ... CASCADE
Дата
Msg-id CAFiTN-t7j=uUdAnU9DJPW4k=0OFWn51g5m=g3Sexs7JRRAKPaA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Logical Replication - behavior of TRUNCATE ... CASCADE  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Ответы Re: Logical Replication - behavior of TRUNCATE ... CASCADE  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: Identify missing publications from publisher while create/alter subscription.
Следующее
От: "houzj.fnst@fujitsu.com"
Дата:
Сообщение: RE: batch fdw insert bug (Postgres 14)