Re: Optionally automatically disable logical replication subscriptions on error
От | Amit Kapila |
---|---|
Тема | Re: Optionally automatically disable logical replication subscriptions on error |
Дата | |
Msg-id | CAA4eK1+TT7Sp2VTFAcFR+wrCWiZCi1rSC5HnffMgYAg4pdxEsw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Optionally automatically disable logical replication subscriptions on error (Mark Dilger <mark.dilger@enterprisedb.com>) |
Ответы |
Re: Optionally automatically disable logical replication subscriptions on error
Re: Optionally automatically disable logical replication subscriptions on error |
Список | 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 по дате отправления: