Re: Optionally automatically disable logical replication subscriptions on error

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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: GUC flags
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Readd use of TAP subtests