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 1nXY4y-0000su-Co for pgsql-hackers@arkaria.postgresql.org; Fri, 25 Mar 2022 00:45:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nXY4x-0006fn-AZ for pgsql-hackers@arkaria.postgresql.org; Fri, 25 Mar 2022 00:45:23 +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 1nXY4w-0006fd-W3 for pgsql-hackers@lists.postgresql.org; Fri, 25 Mar 2022 00:45:22 +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 1nXY4u-0002mf-KW for pgsql-hackers@postgresql.org; Fri, 25 Mar 2022 00:45:21 +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 22P0j7Wf3167048; Thu, 24 Mar 2022 20:45:07 -0400 From: Tom Lane To: Robert Haas cc: Kyotaro Horiguchi , deniel1495@mail.ru, Ibrar Ahmed , tejeswarm@hotmail.com, Andres Freund , hlinnaka , Masahiko Sawada , "pgsql-hackers@postgresql.org" , Daniel Wood Subject: Re: Corruption during WAL replay In-reply-to: References: <20220316.141432.2298656526174566963.horikyota.ntt@gmail.com> <20220318.102109.162855329039722212.horikyota.ntt@gmail.com> <3152696.1648159485@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Thu, 24 Mar 2022 20:39:27 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3167046.1648169107.1@sss.pgh.pa.us> Date: Thu, 24 Mar 2022 20:45:07 -0400 Message-ID: <3167047.1648169107@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Robert Haas writes: > And ... right after hitting send, I see that the recovery check > failures are under separate troubleshooting and thus probably > unrelated. Yeah, we've been chasing those for months. > But that leaves me even more confused. How can a change to > only the server code cause a client utility to fail to detect > corruption that is being created by Perl while the server is stopped? Hmm, I'd supposed that the failing test cases were new as of 412ad7a55. Now I see they're not, which indeed puts quite a different spin on things. Your thought about maybe the server isn't shut down yet is interesting --- did 412ad7a55 touch anything about the shutdown sequence? regards, tom lane