RE: Optionally automatically disable logical replication subscriptions on error

From: "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com>
To: 'Greg Nancarrow' <gregn4422(at)gmail(dot)com>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, "Smith, Peter" <peters(at)fast(dot)au(dot)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: Optionally automatically disable logical replication subscriptions on error
Date: 2021-12-22 10:24:05
Message-ID: TYCPR01MB8373E3F6ABF407AEB98E0A73ED7D9@TYCPR01MB8373.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tuesday, December 21, 2021 11:18 PM I wrote:
> On Thursday, December 16, 2021 9:51 PM I wrote:
> > Attached the updated patch v14.
> FYI, I've conducted a test of disable_on_error flag using pg_upgrade. I
> prepared PG14 and HEAD applied with disable_on_error patch.
> Then, I setup a logical replication pair of the publisher and the subscriber by 14
> and executed pg_upgrade for both the publisher and the subscriber
> individually.
>
> After the updation, on the subscriber, I've confirmed the disable_on_error is
> false via both pg_subscription and \dRs+, as expected.
Additionally, I've tested the new TAP test in a tight loop
that executed 027_disable_on_error.pl 100 times sequentially.
There was no failure, which means
any timing issue should not exist in the test.

Best Regards,
Takamichi Osumi

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Sharma 2021-12-22 10:56:18 Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints
Previous Message osumi.takamichi@fujitsu.com 2021-12-22 10:14:13 RE: Failed transaction statistics to measure the logical replication progress