Re: [PATCH] Logical decoding of TRUNCATE - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [PATCH] Logical decoding of TRUNCATE
Date
Msg-id 2db06ddb-eb96-519a-4a83-59cf8eb9be01@2ndquadrant.com
Whole thread Raw
In response to Re: [PATCH] Logical decoding of TRUNCATE  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [PATCH] Logical decoding of TRUNCATE  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List 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

pgsql-hackers by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: json(b)_to_tsvector with numeric values
Next
From: Simon Riggs
Date:
Subject: Re: [HACKERS] MERGE SQL Statement for PG11