> On Oct 11, 2020, at 1:14 PM, Euler Taveira <euler.tave...@2ndquadrant.com> > wrote: > > >> On Fri, 9 Oct 2020 at 15:54, David Christensen <da...@endpoint.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
