Re: [PATCH] Logical decoding of TRUNCATE

From: Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Logical decoding of TRUNCATE
Date: 2018-01-19 11:37:36
Message-ID: fdd6d0ec-ab81-af7b-aaf6-595c2ac88af9@2ndquadrant.it
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-general pgsql-hackers

Hi All,

Il 18/01/18 17:48, Simon Riggs ha scritto:
> On 17 January 2018 at 17:07, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> wrote:
>
>> Things I am less convinced about:
>>
>> 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).
>
> I agree the default should be to NOT cascade.
>
> If someone wants cascading as a publication option, that can be added later.
>

I agree that not replicating the CASCADE option is the best option
according to POLA principle.

>>> + /* logicalrep_rel_close call not needed, because ExecuteTruncateGuts
>>> + * already closes the relations. Setting localrel to NULL in the map entry
>>> + * is still needed.
>>> + */
>>> + rel->localrel = NULL;
>>
>> This is somewhat ugly. Perhaps the ExecuteTruncateGuts should track
>> which relations it opened and only close those and the rest should be
>> closed by caller? That should also remove the other ugly part which is
>> that the ExecuteTruncateGuts modifies the input list. What if caller
>> wanted to use those relations it sent as parameter later?
>
> Agreed
>

Attached a new version of the patch addressing these issues.

Regards,
Marco

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

Attachment Content-Type Size
0001-truncate_ignore_fks_role_replica.v3.patch text/plain 1.4 KB
0002-logical_decode_truncate.v14.patch text/plain 53.6 KB

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message hmidi slim 2018-01-19 15:34:31 Notify client when a table was full
Previous Message Bjørn T Johansen 2018-01-19 11:33:03 pgaudit?

Browse pgsql-hackers by date

  From Date Subject
Next Message Marco Nenciarini 2018-01-19 11:41:04 Re: [PATCH] session_replication_role = replica with TRUNCATE
Previous Message Greg Stark 2018-01-19 11:28:58 Re: Bug in Physical Replication Slots (at least 9.5)?