Re: [PATCH] Logical decoding of TRUNCATE

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>, Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it>
Cc: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Logical decoding of TRUNCATE
Date: 2018-04-05 15:52:38
Message-ID: 2db06ddb-eb96-519a-4a83-59cf8eb9be01@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On 4/3/18 22:31, Peter Eisentraut wrote:
> The problem I see now is that when we WAL-log a truncate, we include all
> the relids in one record. That seems useful. But during decoding we
> split this into one change per relid. So at the receiving end, truncate
> can only process one relation at a time, which will fail if there are
> foreign keys involved. The solution that had been proposed here was to
> ignore foreign keys on the subscriber, which is clearly problematic.

> I'm going to try to hack up an alternative approach and see how it works
> out.

Done here. I added a separate callback for decoding truncates, which
receives all the relations at once. That information can then be
shipped off together and applied together on the receiving side. So
foreign keys are not a problem anymore. This ended up being a bit
larger than the original patch, but I think it's sound behavior and
future-proof.

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

Attachment Content-Type Size
v19-0001-Logical-decoding-of-TRUNCATE.patch text/plain 27.1 KB
v19-0002-Logical-replication-support-for-TRUNCATE.patch text/plain 41.4 KB

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adam =?utf-8?Q?Sj=C3=B8gren?= 2018-04-05 16:03:23 Re: ERROR: unexpected chunk number 0 (expected 1) for toast value 76753264 in pg_toast_10920100
Previous Message PegoraroF10 2018-04-05 15:45:44 pg_basebackup or dump for starting replication process

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2018-04-05 15:58:46 Re: [HACKERS] MERGE SQL Statement for PG11
Previous Message Dmitry Dolgov 2018-04-05 15:44:51 Re: json(b)_to_tsvector with numeric values