Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n6Mpm-0004u5-UQ for pgsql-hackers@arkaria.postgresql.org; Sun, 09 Jan 2022 01:17:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n6Mpl-0006Z7-PD for pgsql-hackers@arkaria.postgresql.org; Sun, 09 Jan 2022 01:17:21 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n6Mpk-0006Su-Nn for pgsql-hackers@lists.postgresql.org; Sun, 09 Jan 2022 01:17:21 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n6Mpi-0005K6-9a for pgsql-hackers@postgresql.org; Sun, 09 Jan 2022 01:17:19 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 2091HGxt1609153; Sat, 8 Jan 2022 20:17:16 -0500 From: Tom Lane To: Thomas Munro cc: Andrew Dunstan , Alexander Lakhin , pgsql-hackers Subject: Re: Why is src/test/modules/committs/t/002_standby.pl flaky? In-reply-to: <1600941.1641685316@sss.pgh.pa.us> References: <1600941.1641685316@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Sat, 08 Jan 2022 18:41:56 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1609151.1641691036.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sat, 08 Jan 2022 20:17:16 -0500 Message-ID: <1609152.1641691036@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > So for some reason, on these machines detection of walsender-initiated > connection close is unreliable ... or maybe, the walsender didn't close > the connection, but is somehow still hanging around? Don't have much id= ea > where to dig beyond that, but maybe someone else will. I wonder in > particular if this could be related to our recent discussions about > whether to use shutdown(2) on Windows --- could we need to do the > equivalent of 6051857fc/ed52c3707 on walsender connections? ... wait a minute. After some more study of the buildfarm logs, it was brought home to me that these failures started happening just after 6051857fc went in: https://buildfarm.postgresql.org/cgi-bin/show_failures.pl?max_days=3D90&br= anch=3D&member=3D&stage=3Dmodule-commit_tsCheck&filter=3DSubmit The oldest matching failure is jacana's on 2021-12-03. (The above sweep finds an unrelated-looking failure on 2021-11-11, but no others before 6051857fc went in on 2021-12-02. Also, it looks likely that ed52c3707 on 2021-12-07 made the failure more probable, because jacana's is the only matching failure before 12-07.) So I'm now thinking it's highly likely that those commits are causing it somehow, but how? regards, tom lane