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 1lJ4P1-00007Q-N9 for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Mar 2021 01:09: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 1lJ4P0-0004eR-IR for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Mar 2021 01:09:42 +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 1lJ4P0-0004eB-Bm for pgsql-hackers@lists.postgresql.org; Mon, 08 Mar 2021 01:09:42 +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 1lJ4Oy-0008R3-6J for pgsql-hackers@lists.postgresql.org; Mon, 08 Mar 2021 01:09: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 12819Xts1690208; Sun, 7 Mar 2021 20:09:33 -0500 From: Tom Lane To: Thomas Munro cc: Kyotaro Horiguchi , Peter Geoghegan , PostgreSQL Hackers , Craig Ringer , Robert Haas Subject: Re: 011_crash_recovery.pl intermittently fails In-reply-to: References: <20210305.165117.1192284154251506643.horikyota.ntt@gmail.com> <20210305.180819.844001367516475145.horikyota.ntt@gmail.com> <1495174.1614961015@sss.pgh.pa.us> <20210308.093915.2235769710275045679.horikyota.ntt@gmail.com> Comments: In-reply-to Thomas Munro message dated "Mon, 08 Mar 2021 14:03:08 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1690206.1615165773.1@sss.pgh.pa.us> Date: Sun, 07 Mar 2021 20:09:33 -0500 Message-ID: <1690207.1615165773@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Thomas Munro writes: > Thanks! I'm afraid I wouldn't get around to it for a few weeks, so if > you have time, please do. (I'm not sure if it's strictly necessary to > log *this* xid, if a higher xid has already been logged, considering > that the goal is just to avoid getting confused about an xid that is > recycled after crash recovery, but coordinating that might be more > complicated; I don't know.) Yeah, ideally the patch wouldn't add any unnecessary WAL flush, if there's some cheap way to determine that our XID must already have been written out. But I'm not sure that it's worth adding any great amount of complexity to avoid that. For sure I would not advocate adding any new bookkeeping overhead in the mainline code paths to support it. regards, tom lane