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
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 |
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 |