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

From Amit Kapila
Subject Re: Logical Replication - behavior of TRUNCATE ... CASCADE
Date
Msg-id CAA4eK1JdJ-Gn6pN2jKkm5UEykVu9xkDB2QXzBecDxgsBLxxcGw@mail.gmail.com
Whole thread Raw
In response to Re: Logical Replication - behavior of TRUNCATE ... CASCADE  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
List pgsql-hackers
On Mon, May 24, 2021 at 2:18 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> On Mon, May 24, 2021 at 11:22 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > I don't deny that this can allow some additional cases than we allow
> > today but was just not sure whether users really need it. If we want
> > to go with such an option then as mentioned earlier, we should
> > consider another proposal for subscriber-side truncate [1] because we
> > might need a cascade operation there as well but for a slightly
> > different purpose.
>
> I'm thinking how we can utilize the truncate option proposed at [1]
> for the idea here. Because, currently the truncate option(proposed at
> [1]) is boolean, (of course we can change this to take "cascade",
> "restrict" options). But how can we differentiate the usage of the
> truncate option at [1] for two purposes 1) for before copy
> data/initial table sync operation and 2) for the replication of
> TRUNCATE command as proposed here in this thread. Any thoughts?
>

I think we can do this as a separate patch. Let's not try to combine
both patches.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [PATCH] Add `truncate` option to subscription commands
Next
From: Pavan Deolasee
Date:
Subject: Re: Assertion failure while streaming toasted data