Re: [PATCH] session_replication_role = replica with TRUNCATE - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [PATCH] session_replication_role = replica with TRUNCATE
Date
Msg-id c1af5b04-de19-464d-6a80-677a9388288b@2ndquadrant.com
Whole thread Raw
In response to Re: [PATCH] session_replication_role = replica with TRUNCATE  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: [PATCH] session_replication_role = replica with TRUNCATE
List pgsql-hackers
On 1/19/18 05:31, Simon Riggs wrote:
>> I'm not aware of an explanation why it currently works the way it does,
>> other than that FKs happen to be implemented by triggers and triggers
>> happen to work that way.  But I think it's pretty bogus that logical
>> replication subscriptions can insert data that violates constraints.
>> It's also weird that you can violate deferred unique constraints but not
>> immediate ones (I think, not tested).
> 
> The explanation is two-fold.
> 
> 1. If we pass valid data from the publisher, it should still be valid
> data when it gets there.

That is not necessarily the case, because we allow independent writes on
the subscriber.  The current test suite contains an example that you can
create invalid data this way.

> If we cannot apply changes then the
> subscriber is broken and the subscription cannot continue, so
> executing the a constraint trigger does not solve the problem.

But that is already the case for any other kind of constraint or type
violation.  Just that certain kinds of constraints are apparently
ignored for no clear reason.

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


pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: [HACKERS] GSOC'17 project introduction: Parallel COPY executionwith errors handling
Next
From: Peter Eisentraut
Date:
Subject: Re: [PATCH] session_replication_role = replica with TRUNCATE