Re: [PATCH] Logical decoding of TRUNCATE

From: Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Logical decoding of TRUNCATE
Date: 2018-01-02 18:11:11
Message-ID: f7b0fe6b-d564-87cc-9b57-3c01d00480dd@2ndquadrant.it
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Hi,

Il 29/12/17 20:55, Andres Freund ha scritto:
> 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.
>

here is the description of how the patch works:

* A new WAL record type has been added (XLOG_HEAP_TRUNCATE) to allow a
precise logical decoding of the TRUNCATE operation. It contains the
TRUNCATE flags and the list of the involved tables and sequences. It is
treated as a NO-OP during the WAL reply as all the physical operations
are logged in SMGR WAL records.

* A new TRUNCATE message has been added to the logical protocol. It
carries the information about the truncation of one single table
specifying if CASCADE or RESTART IDENTITY has been specified.

* The ExecuteTruncateGuts function has been extracted from
ExecuteTruncate. This function is used by the logical apply process to
replicate the TRUNCATE operations, honouring the eventual CASCADE and
RESTART IDENTITY flag.

Regards,
Marco

--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco(dot)nenciarini(at)2ndQuadrant(dot)it | www.2ndQuadrant.it

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Martin Moore 2018-01-02 21:28:39 Re: Slow system due to ReorderBufferGetTupleBuf?
Previous Message Graeme 2018-01-02 16:37:31 Re: Use of Port 5433 with Postgresql 9.6

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2018-01-02 18:12:13 Re: AS OF queries
Previous Message Pavel Stehule 2018-01-02 17:19:50 Re: [HACKERS] SQL procedures