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

From Simon Riggs
Subject Re: [PATCH] Logical decoding of TRUNCATE
Date
Msg-id CANP8+jKe2MxtH4Ck70tUY6wP=OnkkkXRt8Xkx1u6+50HM2wHvQ@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Logical decoding of TRUNCATE  (Andres Freund <andres@anarazel.de>)
Responses Re: [PATCH] Logical decoding of TRUNCATE
Logical decoding of TRUNCATE vs DELETE
Logical decoding of TRUNCATE vs DELETE
List 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 by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Unimpressed with pg_attribute_always_inline
Next
From: Alvaro Herrera
Date:
Subject: Re: Enhance pg_stat_wal_receiver view to display connected host