Re: [PATCH] Logical decoding of TRUNCATE - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [PATCH] Logical decoding of TRUNCATE
Date
Msg-id CA+TgmoZa+7LmTdONSEQUHpF30M8nAH4-2Ub3hE_7ncuSdVTvKQ@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Logical decoding of TRUNCATE  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Responses Re: [PATCH] Logical decoding of TRUNCATE
List pgsql-hackers
On Wed, Jan 17, 2018 at 12:07 PM, Petr Jelinek
<petr.jelinek@2ndquadrant.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.

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


pgsql-hackers by date:

Previous
From: "Tsunakawa, Takayuki"
Date:
Subject: RE: [HACKERS][PATCH] Applying PMDK to WAL operations for persistentmemory
Next
From: "Tsunakawa, Takayuki"
Date:
Subject: RE: [HACKERS][PATCH] Applying PMDK to WAL operations for persistentmemory