Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Subject: Re: Optionally automatically disable logical replication
 subscriptions on error
From: Mark Dilger <mark.dilger@enterprisedb.com>
In-Reply-To: 
 <CAA4eK1+VS6LiD844jOArYTXTgWfiDVUmUmbP_1gG-PvYXp_JEA@mail.gmail.com>
Date: Sun, 5 Dec 2021 20:37:44 -0800
Cc: "osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>,
 vignesh C <vignesh21@gmail.com>,
 Greg Nancarrow <gregn4422@gmail.com>,
 Masahiko Sawada <sawada.mshk@gmail.com>,
 "Smith, Peter" <peters@fast.au.fujitsu.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D7470973-CEF5-4564-B03D-65A60836EDD5@enterprisedb.com>
References: <DB35438F-9356-4841-89A0-412709EBD3AB@enterprisedb.com>
 <CAA4eK1KkhsNAW3=XxOdVRD9+RcQG5PRRFBFzAMibMG0YFFmAmg@mail.gmail.com>
 <B522A0FA-0B5C-4A66-9B73-928CAA86FB88@enterprisedb.com>
 <CAA4eK1KM23D06_rUEsgnTFUpABoeCCoTun2TMrQzWgxWOYY7fA@mail.gmail.com>
 <DE7E13B7-DC76-416A-A98F-3BC3F80E6BE9@enterprisedb.com>
 <CAD21AoB+QH4or-QDiakALZp6pkXiAaGxfGcsvNYJoDHk9kknZw@mail.gmail.com>
 <F25752DE-45EC-4DDE-97D9-75F270FB67CD@enterprisedb.com>
 <CAD21AoCPSU-MBHkortBnELO7Hu0tLsX5GoOEbSYzyxKBPkKvBg@mail.gmail.com>
 <TYCPR01MB837384DA6C879A709EBF30D1ED8B9@TYCPR01MB8373.jpnprd01.prod.outlook.com>
 <CALDaNm0bXsyrXg3dQGbAhkUDGKnFXtM6mKk8d-8VFLo6wz3ZJA@mail.gmail.com>
 <TYCPR01MB8373934498C93D1A1466A2E3ED939@TYCPR01MB8373.jpnprd01.prod.outlook.com>
 <CAJcOf-ci4NeNwowE=BmtSWip2NRgZdGe-VFjvSDY2JP0NNLTMQ@mail.gmail.com>
 <TYCPR01MB8373D8A622ED51CDEF3DAF5DED949@TYCPR01MB8373.jpnprd01.prod.outlook.com>
 <CALDaNm0PdzqVSy0uUZ+UKd9rQeQONUjkALj3Ge+fAmdw0cSLgA@mail.gmail.com>
 <TYCPR01MB8373771371B31E1E6CC74B0AED999@TYCPR01MB8373.jpnprd01.prod.outlook.com>
 <CAJcOf-f6oqtKt2CD-KcUH00=3+Bybym7magDenegOao2YE-SZQ@mail.gmail.com>
 <TYCPR01MB837308EA9546476CFA0C53F0ED9B9@TYCPR01MB8373.jpnprd01.prod.outlook.com>
 <CALDaNm2g8E-cF+6DzzMe8zdeCt6Ktd454_1UFBRA+2jE3si3Zg@mail.gmail.com>
 <TYCPR01MB837398F781D4B21A94B4EDE0ED639@TYCPR01MB8373.jpnprd01.prod.outlook.com>
 <CAJcOf-c6TC37C7w4JKFDLxs3XaQO3tqhW3792T-_tv-a7hi5uA@mail.gmail.com>
 <TYCPR01MB83735AA021E0F614A3AB3221ED679@TYCPR01MB8373.jpnprd01.prod.outlook.com>
 <CALDaNm309nOxCtX0SOwHdUUp7LkrR9AYyjggGhy0zv1=2FWoiQ@mail.gmail.com>
 <TYCPR01MB8373369C42D82D8F85E4AA83ED689@TYCPR01MB8373.jpnprd01.prod.outlook.com>
 <CAA4eK1+VtBf4QC7CCd91Fh=VD_aXt83dGVVEP64YyBubEW1kVQ@mail.gmail.com>
 <TYCPR01MB83730B37108684983C8F690DED699@TYCPR01MB8373.jpnprd01.prod.outlook.com>
 <CAA4eK1+VS6LiD844jOArYTXTgWfiDVUmUmbP_1gG-PvYXp_JEA@mail.gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/D7470973-CEF5-4564-B03D-65A60836EDD5%40enterprisedb.com>
Precedence: bulk


> On Dec 1, 2021, at 8:48 PM, Amit Kapila <amit.kapila16@gmail.com> =
wrote:
>=20
> The patch disables the subscription for non-transient errors. I am not
> sure if we can easily make the call to decide whether any particular
> error is transient or not. For example, DISK_FULL or OUT_OF_MEMORY
> might not rectify itself. Why not just allow to disable the
> subscription on any error? And then let the user check the error
> either in view or logs and decide whether it would like to enable the
> subscription or do something before it (like making space in disk, or
> fixing the network).

The original idea of the patch, back when I first wrote and proposed it, =
was to remove the *absurdity* of retrying a transaction which, in the =
absence of human intervention, was guaranteed to simply fail again ad =
infinitum.  Retrying in the face of resource errors is not *absurd* even =
though it might fail again ad infinitum.  The reason is that there is at =
least a chance that the situation will clear up without human =
intervention.

> The other problem I see with this transient error stuff is maintaining
> the list of error codes that we think are transient. I think we need a
> discussion for each of the error_codes we are listing now and whatever
> new error_code we add in the future which doesn't seem like a good
> idea.

A reasonable rule might be:  "the subscription will be disabled if the =
server can determine that retries cannot possibly succeed without human =
intervention."  We shouldn't need to categorize all error codes =
perfectly, as long as we're conservative.  What I propose is similar to =
how we determine whether to mark a function leakproof; we don't have to =
mark all leakproof functions as such, we just can't mark one as such if =
it is not.

If we're going to debate the error codes, I think we would start with an =
empty list, and add to the list on sufficient analysis.

=E2=80=94
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company