Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\))
Subject: Re: Optionally automatically disable logical replication
 subscriptions on error
From: Mark Dilger <mark.dilger@enterprisedb.com>
In-Reply-To: 
 <CAA4eK1+TT7Sp2VTFAcFR+wrCWiZCi1rSC5HnffMgYAg4pdxEsw@mail.gmail.com>
Date: Sun, 20 Jun 2021 22:25:48 -0700
Cc: 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: <A539C848-670E-454F-B31C-82D3CBE9F5AC@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>
 <CAA4eK1+NoRbYSH1J08zi4OJ_EUMcjmxTwnmwVqZ6e_xzS0D6VA@mail.gmail.com>
 <14738A39-8000-463E-A0BA-6729930A32DA@enterprisedb.com>
 <CAA4eK1+TT7Sp2VTFAcFR+wrCWiZCi1rSC5HnffMgYAg4pdxEsw@mail.gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/A539C848-670E-454F-B31C-82D3CBE9F5AC%40enterprisedb.com>
Precedence: bulk


> On Jun 20, 2021, at 10:11 PM, Amit Kapila <amit.kapila16@gmail.com> =
wrote:
>=20
> 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.

Right, I wasn't trying to capture everything, just enough to give the =
user a reasonable indication of what went wrong.  My patch was designed =
around the idea that the user would need to figure out how to fix the =
subscriber side prior to re-enabling the subscription.  As such, I =
wasn't bothered with trying to store everything, just enough to give the =
user a clue where to look.  I don't mind if you want to store more =
information, and maybe that needs to be stored somewhere else.  Do you =
believe pg_subscription_rel is a suitable location?=20

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