Re: [PATCH] Logical decoding of TRUNCATE

On Thu, Jan 25, 2018 at 8:36 PM, Petr Jelinek
<petr(dot)jelinek(at)2ndquadrant(dot)com> wrote:
> 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.

Oh. That's different. :-)

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company