Re: [PATCH] Logical decoding of TRUNCATE

On 26/01/18 02:34, Robert Haas wrote:
> On Wed, Jan 17, 2018 at 12:07 PM, Petr Jelinek
> <petr(dot)jelinek(at)2ndquadrant(dot)com> wrote:
>> The patch will cascade truncation on downstream if cascade was specified
>> on the upstream, that can potentially be dangerous and we either should
>> not do it and only truncate the tables which were truncated upstream
>> (but without restricting because of FKs), leaving the data inconsistent
>> on downstream (like we do already with DELETE or UPDATE). Or maybe make
>> it into either subscription or publication option so that user can chose
>> the behaviour here as I am sure some people will want it to cascade (but
>> the default should still IMHO be to not cascade as that's safer).
>
> Maybe I'm not understanding what is being proposed here, but it sounds
> like you're saying that if somebody removes a bunch of data on the
> logical master, replication will remove only some of it from the
> servers to which the change is replicated. That seems crazy. Then
> replication can't be counted on to produce a replica.
>

No, I was talking about extra tables that might be present on downstream
which weren't truncated on upstream.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services