Date: Tue, 13 Dec 2022 16:01:45 -0800
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Melih Mutlu <m.melihmutlu@gmail.com>,
	Thomas Munro <thomas.munro@gmail.com>,
	"Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: wake up logical workers after ALTER SUBSCRIPTION
Message-ID: <20221214000145.GA638663@nathanxps13>
References: 
 <CA+hUKGJXO6LUn3wTf3s0Z8DvgbQROxPTnJDHCsQrhbr3pF3g8Q@mail.gmail.com>
 <20221130050441.GA1677223@nathanxps13>
 <20221202002130.GA2124877@nathanxps13>
 <20221202192101.GB2277157@nathanxps13>
 <CAGPVpCTUuKyxB5f3exgDMBRTivbN5uHVkD=YfXmgznrdnwVOQw@mail.gmail.com>
 <20221206192551.GA3078082@nathanxps13>
 <20221206212954.GA3403597@nathanxps13>
 <CAGPVpCTkdaOyBLXB435VXq0RA1cHLFQut7BPm6t8D4dsdiEXZQ@mail.gmail.com>
 <20221207181145.GA3698731@nathanxps13>
 <2550453.1670974328@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2550453.1670974328@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/20221214000145.GA638663%40nathanxps13>
Precedence: bulk

On Tue, Dec 13, 2022 at 06:32:08PM -0500, Tom Lane wrote:
> Before, there was up to 1 second (with multiple "SELECT count(1) = 0"
> probes from the test script) between the ALTER SUBSCRIPTION command
> and the "apply worker will restart" log entry.  That wait is pretty
> well zapped, but instead now we're waiting hundreds of ms for the
> "apply worker has started" message.
> 
> I've not chased it further than that, but I venture that the apply
> launcher also needs a kick in the pants, and/or there needs to be
> an interlock to ensure that it doesn't wake until after the old
> apply worker quits.

This is probably because the tests set wal_retrieve_retry_interval to
500ms.  Lowering that to 1ms in Cluster.pm seems to wipe out this
particular wait, and the total src/test/subscription test time drops from
119 seconds to 95 seconds on my machine.  This probably lowers the amount
of test coverage we get on the wal_retrieve_retry_interval code paths, but
if that's a concern, perhaps we should write a test specifically for
wal_retrieve_retry_interval.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com