Date: Sun, 30 Jun 2024 14:08:17 -0700
From: Noah Misch <noah@leadboat.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>,
	Peter Eisentraut <peter@eisentraut.org>,
	Alexander Lakhin <exclusion@gmail.com>,
	Euler Taveira <euler@eulerto.com>,
	Amit Kapila <amit.kapila16@gmail.com>,
	Shlok Kyal <shlok.kyal.oss@gmail.com>,
	Tomas Vondra <tomas.vondra@enterprisedb.com>,
	"kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>,
	Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
	"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
	Michael Paquier <michael@paquier.xyz>,
	Andres Freund <andres@anarazel.de>,
	Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
	=?iso-8859-1?Q?Fabr=EDzio?= de Royes Mello <fabriziomello@gmail.com>,
	vignesh C <vignesh21@gmail.com>
Subject: Re: speed up a logical replica setup
Message-ID: <20240630210817.51.nmisch@google.com>
References: 
 <CAA4eK1JaQcAZ=n513-4VDW4ujE9T9f007fczNCpVDbg1smhT4g@mail.gmail.com>
 <5da4b286-e570-4341-8262-92d763f6b1a4@app.fastmail.com>
 <776c5cac-5ef5-4001-b1bc-5b698bc0c62a@app.fastmail.com>
 <3c024250-3f13-4f4d-b8e9-55f176db4abf@eisentraut.org>
 <0dffca12-bf17-4a7a-334d-225569de5e6e@gmail.com>
 <2377319.1719766794@sss.pgh.pa.us>
 <2507765.1719772840@sss.pgh.pa.us>
 <2509767.1719773880@sss.pgh.pa.us>
 <20240630192534.11.nmisch@google.com>
 <2522388.1719781312@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2522388.1719781312@sss.pgh.pa.us>
User-Agent: Mutt/2.2.12 (2023-09-09)
Archived-At: 
 <https://www.postgresql.org/message-id/20240630210817.51.nmisch%40google.com>
Precedence: bulk

On Sun, Jun 30, 2024 at 05:01:52PM -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > On Sun, Jun 30, 2024 at 02:58:00PM -0400, Tom Lane wrote:
> >> So b3f5ccebd promptly blew up on fairywren [1]:
> 
> > It does look consistent with IPC::Run predating v20220807.0, hence lacking the
> > https://github.com/toddr/IPC-Run/issues/142 fix.  I wondered how this animal
> > was passing 002_pg_upgrade.pl, but it seems the animal has run TAP suites only
> > occasionally.  Passes in the last week were TAP-free.
> 
> Hmm, drongo just failed in the same way.  (It seems to likewise
> run TAP tests only some of the time, which I don't understand
> because the $Script_Config output looks the same between runs
> with TAP tests and runs without.)

On further reflection, 002_pg_upgrade.pl may not fail with old IPC::Run.  It
may just create a database with an unintended name, losing some test coverage.

> I'm tempted to lobotomize the new test case on Windows until
> we have that resolved.

Sounds fine.  The pg_upgrade suite adequately tests appendShellString() and
appendConnStrVal() with the larger character repertoire, so it's enough for
pg_createsubscriber to test just a space or so.