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 1n7NZk-0005S1-3f for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Jan 2022 20:17:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n7NZi-0002MF-Q7 for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Jan 2022 20:16:58 +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 1n7NZi-0002Lu-Gb for pgsql-hackers@lists.postgresql.org; Tue, 11 Jan 2022 20:16:58 +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 1n7NZc-00024t-5S for pgsql-hackers@postgresql.org; Tue, 11 Jan 2022 20:16:57 +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 20BKGoMg2763902; Tue, 11 Jan 2022 15:16:50 -0500 From: Tom Lane To: Thomas Munro cc: Alexander Lakhin , Andrew Dunstan , pgsql-hackers Subject: Re: Why is src/test/modules/committs/t/002_standby.pl flaky? In-reply-to: References: <1600941.1641685316@sss.pgh.pa.us> <1609152.1641691036@sss.pgh.pa.us> <3b904d7b-ef84-6f1b-9326-9f88c1374eb8@gmail.com> <5d507424-13ce-d19f-2f5d-ab4c6a987316@gmail.com> <1fe6b898-1722-d190-03c0-bf4c4884a748@gmail.com> Comments: In-reply-to Thomas Munro message dated "Wed, 12 Jan 2022 09:10:42 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2763900.1641932210.1@sss.pgh.pa.us> Date: Tue, 11 Jan 2022 15:16:50 -0500 Message-ID: <2763901.1641932210@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Thomas Munro writes: > Ouch. I think our options at this point are: > 1. Revert 6051857fc (and put it back when we have a working > long-lived WES as I showed). This is not very satisfying, now that we > understand the bug, because even without that change I guess you must > be able to reach the hanging condition by using Windows postgres_fdw > to talk to a non-Windows server (ie a normal TCP stack with graceful > shutdown/linger on process exit). It'd be worth checking, perhaps. One thing I've been wondering all along is how much of this behavior is specific to the local-loopback case where Windows can see both ends of the connection. You'd think that they couldn't long get away with such blatant violations of the TCP specs when talking to external servers, because the failures would be visible to everyone with a web browser. regards, tom lane