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

From Amit Kapila
Subject Re: Optionally automatically disable logical replication subscriptions on error
Date
Msg-id CAA4eK1+TT7Sp2VTFAcFR+wrCWiZCi1rSC5HnffMgYAg4pdxEsw@mail.gmail.com
Whole thread Raw
In response to Re: Optionally automatically disable logical replication subscriptions on error  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: Optionally automatically disable logical replication subscriptions on error
Re: Optionally automatically disable logical replication subscriptions on error
List pgsql-hackers
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
addnon-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.



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: PG 14 release notes, first draft
Next
From: Mark Dilger
Date:
Subject: Re: Optionally automatically disable logical replication subscriptions on error