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

From: David Christensen <david(at)endpoint(dot)com>
To: Euler Taveira <euler(dot)taveira(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Add `truncate` option to subscription commands
Date: 2020-10-11 22:13:55
Message-ID: A2D43BA8-B5CE-48FB-9323-5A1F88504953@endpoint.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> 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.

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.

But you would definitely want to avoid “truncate cascade” if the FK target tables were already in the publication, unless we were willing to re-sync the other tables that would be truncated.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-10-12 01:01:08 Re: BUG #15858: could not stat file - over 4GB
Previous Message Christoph Berg 2020-10-11 18:35:13 Re: powerpc pg_atomic_compare_exchange_u32_impl: error: comparison of integer expressions of different signedness (Re: pgsql: For all ppc compilers, implement compare_exchange and) fetch_add