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 1lI2GZ-0006iL-7V for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Mar 2021 04:40:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lI2GY-0000cH-0D for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Mar 2021 04:40:42 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lI2GX-0000cA-Pd for pgsql-hackers@lists.postgresql.org; Fri, 05 Mar 2021 04:40:41 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lI2GV-0004dt-Ft for pgsql-hackers@lists.postgresql.org; Fri, 05 Mar 2021 04:40:41 +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 1254eYlQ1439486; Thu, 4 Mar 2021 23:40:34 -0500 From: Tom Lane To: Thomas Munro cc: Peter Geoghegan , Kyotaro Horiguchi , PostgreSQL Hackers , Craig Ringer , Robert Haas Subject: Re: 011_crash_recovery.pl intermittently fails In-reply-to: References: <20210305.115011.558061052471425531.horikyota.ntt@gmail.com> <1436448.1614915141@sss.pgh.pa.us> <1437508.1614916929@sss.pgh.pa.us> <1437804.1614917445@sss.pgh.pa.us> Comments: In-reply-to Thomas Munro message dated "Fri, 05 Mar 2021 17:30:58 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1439484.1614919234.1@sss.pgh.pa.us> Date: Thu, 04 Mar 2021 23:40:34 -0500 Message-ID: <1439485.1614919234@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Thomas Munro writes: > On Fri, Mar 5, 2021 at 5:10 PM Tom Lane wrote: >> Alternatively, maybe we can salvage the function's usefulness by making it >> flush WAL before returning? > To make pg_xact_status()'s result reliable, don't you need to make > pg_current_xact_id() flush? In other words, isn't it at the point > that you *observe* the transaction that you have to make sure that > this transaction ID won't be reused after crash recovery. Before > that, it's simultaneously allocated and unallocated, like the cat. We need to be sure that the XID is written out to WAL before we let the client see it, yeah. I've not looked to see exactly where in the code would be the best place. BTW, I tried simply removing the "allows_streaming" option from the test, and it failed ten times out of ten tries for me. So Andres is right that that makes it pretty reproducible in a stock build. regards, tom lane