Re: [PATCH] Logical decoding of TRUNCATE

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: [PATCH] Logical decoding of TRUNCATE
Дата
Msg-id CANP8+jKe2MxtH4Ck70tUY6wP=OnkkkXRt8Xkx1u6+50HM2wHvQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Logical decoding of TRUNCATE  (Andres Freund <andres@anarazel.de>)
Ответы Re: [PATCH] Logical decoding of TRUNCATE
Logical decoding of TRUNCATE vs DELETE
Logical decoding of TRUNCATE vs DELETE
Список pgsql-hackers
On 29 December 2017 at 19:55, Andres Freund <andres@anarazel.de> wrote:
> Hi,
>
> On 2017-12-29 14:15:22 +0100, Marco Nenciarini wrote:
>> This patch implements support for TRUNCATE statements
>> in logical replication. The work has mainly done by Simon Riggs then
>> finished by me. Tests are written by me.
>>
>> TRUNCATE is treated as a form of DELETE for the purpose of deciding
>> whether to publish, or not.
>
> It'd be good if you explained exactly what the chosen behaviour is, and
> why that's the right behaviour in comparison to other alternatives.

At present the patch treats TRUNCATE as if it were a DELETE

which means that

CREATE PUBLICATION insert_only FOR TABLE mydata WITH (publish = 'insert');
will not publish truncates before or after this patch

CREATE PUBLICATION insert_only FOR TABLE mydata;
will now publish TRUNCATEs, although they were ignored in PG10
so PG10 publications will act differently

I had regarded it as a missing piece, but some may view that is a
behaviour change in PG11

Alternatively, we could also use WITH (publish = 'truncate') as a
separate decision.

That is an easy change if we wish it.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Unimpressed with pg_attribute_always_inline
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Enhance pg_stat_wal_receiver view to display connected host