Re: Optionally automatically disable logical replication subscriptions on error - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: Optionally automatically disable logical replication subscriptions on error
Date
Msg-id 14738A39-8000-463E-A0BA-6729930A32DA@enterprisedb.com
Whole thread Raw
In response to Re: Optionally automatically disable logical replication subscriptions on error  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Optionally automatically disable logical replication subscriptions on error
List pgsql-hackers

> On Jun 20, 2021, at 8:09 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> Because currently, we don't proceed after an error unless it is
> resolved. Why do you think there could be multiple such transactions?

Just as one example, if the subscriber has a unique index that the publisher lacks, any number of transactions could
addnon-unique data that then fails to apply on the subscriber.  My patch took the view that the user should figure out
howto get the subscriber side consistent with the publisher side, but if you instead take the approach that problematic
commitsshould be skipped, it would seem that arbitrarily many such transactions could be committed on the publisher
side.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






pgsql-hackers by date:

Previous
From: Sandeep Thakkar
Date:
Subject: Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.
Next
From: Amit Kapila
Date:
Subject: Re: [bug?] Missed parallel safety checks, and wrong parallel safety