Re: [PATCH] Add `truncate` option to subscription commands

On Mon, Oct 12, 2020 at 3:44 AM David Christensen <david(at)endpoint(dot)com> wrote:
>
>
> On Oct 11, 2020, at 1:14 PM, Euler Taveira <euler(dot)taveira(at)2ndquadrant(dot)com> wrote:
>
> 
> On Fri, 9 Oct 2020 at 15:54, David Christensen <david(at)endpoint(dot)com> wrote:
>>
>>
>> Enclosed find a patch to add a “truncate” option to subscription commands.
>>
>> When adding new tables to a subscription (either via `CREATE SUBSCRIPTION` or `REFRESH PUBLICATION`), tables on the target which are being newly subscribed will be truncated before the data copy step. This saves explicit coordination of a manual `TRUNCATE` on the target tables and allows the results of the initial data sync to be the same as on the publisher at the time of sync.
>>
>> To preserve compatibility with existing behavior, the default value for this parameter is `false`.
>>
>
> Truncate will fail for tables whose foreign keys refer to it. If such a feature cannot handle foreign keys, the usefulness will be restricted.
>
>
> This is true for existing “truncate” with FKs, so doesn’t seem to be any different to me.
>

What would happen if there are multiple tables and truncate on only
one of them failed due to FK check? Does it give an error in such a
case, if so will the other tables be truncated?

> Hypothetically if you checked all new tables and could verify if there were FK cycles only already in the new tables being added then “truncate cascade” would be fine. Arguably if they had existing tables that were part of an FK that wasn’t fully replicated they were already operating brokenly.
>

I think if both PK_table and FK_table are part of the same
subscription then there should be a problem as both them first get
truncated? If they are part of a different subscription (or if they
are not subscribed due to whatever reason) then probably we need to
deal such cases carefully.

--
With Regards,
Amit Kapila.