Re: [PATCH] Logical decoding of TRUNCATE

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [PATCH] Logical decoding of TRUNCATE
Дата
Msg-id CA+TgmoZa+7LmTdONSEQUHpF30M8nAH4-2Ub3hE_7ncuSdVTvKQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Logical decoding of TRUNCATE  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Ответы Re: [PATCH] Logical decoding of TRUNCATE
Список 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 по дате отправления:

Предыдущее
От: "Tsunakawa, Takayuki"
Дата:
Сообщение: RE: [HACKERS][PATCH] Applying PMDK to WAL operations for persistentmemory
Следующее
От: "Tsunakawa, Takayuki"
Дата:
Сообщение: RE: [HACKERS][PATCH] Applying PMDK to WAL operations for persistentmemory