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

From Mark Dilger
Subject Re: Optionally automatically disable logical replication subscriptions on error
Date
Msg-id 92A72C94-42DC-4873-8CBD-95518154E4B3@enterprisedb.com
Whole thread Raw
In response to RE: Optionally automatically disable logical replication subscriptions on error  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
Responses Re: Optionally automatically disable logical replication subscriptions on error  (Greg Nancarrow <gregn4422@gmail.com>)
List pgsql-hackers

> On Dec 5, 2021, at 10:56 PM, osumi.takamichi@fujitsu.com wrote:
>
> In my humble opinion, I felt the original purpose of the patch was to partially remedy
> the situation that during the failure of apply, the apply process keeps going
> into the infinite error loop.

I agree.

> I'd say that in this sense, if we include such resource errors, we fail to achieve
> the purpose in some cases, because of some left possibilities of infinite loop.
> Disabling the subscription with even one any error excludes this irregular possibility,
> since there's no room to continue the infinite loop.

I don't think there is any right answer here.  It's a question of policy preferences.

My concern about disabling a subscription in response to *any* error is that people may find the feature does more harm
thangood.  Disabling the subscription in response to an occasional deadlock against other database users, or occasional
resourcepressure, might annoy people and lead to the feature simply not being used. 

I am happy to defer to your policy preference.  Thanks for your work on the patch!

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: should we document an example to set multiple libraries in shared_preload_libraries?
Next
From: Robert Haas
Date:
Subject: Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints