Re: [PATCH] Logical decoding of TRUNCATE
От | Petr Jelinek |
---|---|
Тема | Re: [PATCH] Logical decoding of TRUNCATE |
Дата | |
Msg-id | 5c6ede4a-1d58-fbdf-1faf-af024527a579@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Logical decoding of TRUNCATE (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [PATCH] Logical decoding of TRUNCATE
|
Список | pgsql-hackers |
On 26/01/18 02:34, Robert Haas wrote: > 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. > 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
В списке pgsql-hackers по дате отправления: