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 CAA4eK1JG28oJqCM1VU1J0bzOAt1tcx+6c-YG5t=u1KF_Q1FESw@mail.gmail.com
Whole thread Raw
In response to Re: Optionally automatically disable logical replication subscriptions on error  (Greg Nancarrow <gregn4422@gmail.com>)
Responses Re: Optionally automatically disable logical replication subscriptions on error  (Mark Dilger <mark.dilger@enterprisedb.com>)
List pgsql-hackers
On Tue, Dec 7, 2021 at 5:52 AM Greg Nancarrow <gregn4422@gmail.com> wrote:
>
> On Tue, Dec 7, 2021 at 3:06 AM Mark Dilger <mark.dilger@enterprisedb.com> wrote:
> >
> > My concern about disabling a subscription in response to *any* error is that people may find the feature does more
harmthan good.  Disabling the subscription in response to an occasional deadlock against other database users, or
occasionalresource pressure, might annoy people and lead to the feature simply not being used. 
> >
> I can understand this point of view.
> It kind of suggests to me the possibility of something like a
> configurable timeout (e.g. disable the subscription if the same error
> has occurred for more than X minutes) or, similarly, perhaps if some
> threshold has been reached (e.g. same error has occurred more than X
> times), but I think that this was previously suggested by Peter Smith
> and the idea wasn't looked upon all that favorably?
>

I think if we are really worried about transient errors then probably
the idea "disable only if the same error has occurred more than X
times" seems preferable as compared to taking a decision on which
error_codes fall in the transient error category.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: GUC flags
Next
From: Peter Eisentraut
Date:
Subject: Readd use of TAP subtests