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