MIME-Version: 1.0
References: <DB35438F-9356-4841-89A0-412709EBD3AB@enterprisedb.com>
 <CAA4eK1KkhsNAW3=XxOdVRD9+RcQG5PRRFBFzAMibMG0YFFmAmg@mail.gmail.com>
 <B522A0FA-0B5C-4A66-9B73-928CAA86FB88@enterprisedb.com>
 <CAA4eK1KM23D06_rUEsgnTFUpABoeCCoTun2TMrQzWgxWOYY7fA@mail.gmail.com>
 <DE7E13B7-DC76-416A-A98F-3BC3F80E6BE9@enterprisedb.com>
 <CAD21AoB+QH4or-QDiakALZp6pkXiAaGxfGcsvNYJoDHk9kknZw@mail.gmail.com>
 <F25752DE-45EC-4DDE-97D9-75F270FB67CD@enterprisedb.com>
 <CAA4eK1+NoRbYSH1J08zi4OJ_EUMcjmxTwnmwVqZ6e_xzS0D6VA@mail.gmail.com>
 <14738A39-8000-463E-A0BA-6729930A32DA@enterprisedb.com>
In-Reply-To: <14738A39-8000-463E-A0BA-6729930A32DA@enterprisedb.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Mon, 21 Jun 2021 10:41:51 +0530
Message-ID: 
 <CAA4eK1+TT7Sp2VTFAcFR+wrCWiZCi1rSC5HnffMgYAg4pdxEsw@mail.gmail.com>
Subject: Re: Optionally automatically disable logical replication
 subscriptions on error
To: Mark Dilger <mark.dilger@enterprisedb.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, "Smith,
 Peter" <peters@fast.au.fujitsu.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAA4eK1%2BTT7Sp2VTFAcFR%2BwrCWiZCi1rSC5HnffMgYAg4pdxEsw%40mail.gmail.com>
Precedence: bulk

On Mon, Jun 21, 2021 at 10:24 AM Mark Dilger
<mark.dilger@enterprisedb.com> wrote:
>
> > 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 add non-unique data that then fails to apply on the subscriber.
>

Then also it will fail on the first such conflict, so even without
your patch, the apply worker corresponding to the subscription won't
be able to proceed after the first error, it won't lead to multiple
failing xids. However, I see a different case where there could be
multiple failing xids and that can happen during initial table sync
where multiple workers failed due to some error. I am not sure your
patch would be able to capture all such failed transactions because
you are recording this information in pg_subscription and not in
pg_subscription_rel.

-- 
With Regards,
Amit Kapila.