Date: Sun, 18 Dec 2022 15:36:07 -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: <20221218233607.GB1476904@nathanxps13>
References: <2561155.1670977214@sss.pgh.pa.us>
 <20221214004105.GA669835@nathanxps13>
 <20221214171023.GA689106@nathanxps13>
 <2707695.1671039752@sss.pgh.pa.us>
 <20221214174535.GA773264@nathanxps13>
 <2783450.1671042198@sss.pgh.pa.us>
 <20221214183759.GC773264@nathanxps13>
 <2787771.1671044578@sss.pgh.pa.us>
 <20221214231727.GA828014@nathanxps13>
 <20221215224721.GA694065@nathanxps13>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20221215224721.GA694065@nathanxps13>
Archived-At: 
 <https://www.postgresql.org/message-id/20221218233607.GB1476904%40nathanxps13>
Precedence: bulk

On Thu, Dec 15, 2022 at 02:47:21PM -0800, Nathan Bossart wrote:
> I tried setting wal_retrieve_retry_interval to 1ms for all TAP tests
> (similar to what was done in 2710ccd), and I noticed that the recovery
> tests consistently took much longer.  Upon further inspection, it looks
> like the same (or a very similar) race condition described in e5d494d's
> commit message [0].  With some added debug logs, I see that all of the
> callers of MaybeStartWalReceiver() complete before SIGCHLD is processed, so
> ServerLoop() waits for a minute before starting the WAL receiver.
> 
> A simple fix is to have DetermineSleepTime() take the WalReceiverRequested
> flag into consideration.  The attached 0002 patch shortens the sleep time
> to 100ms if it looks like we are waiting on a SIGCHLD.  I'm not certain
> this is the best approach, but it seems to fix the tests.

This seems to have somehow broken the archiving tests on Windows, so
obviously I owe some better analysis here.  I didn't see anything obvious
in the logs, but I will continue to dig.

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