Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fsOF4-00084a-1C for pgsql-bugs@arkaria.postgresql.org; Wed, 22 Aug 2018 08:11:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fsOF0-0005KE-Qt for pgsql-bugs@arkaria.postgresql.org; Wed, 22 Aug 2018 08:11:46 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fsOEz-0005K6-5w for pgsql-bugs@lists.postgresql.org; Wed, 22 Aug 2018 08:11:46 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fsOEn-0000Aa-74 for pgsql-bugs@lists.postgresql.org; Wed, 22 Aug 2018 08:11:44 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 153E121BE6; Wed, 22 Aug 2018 04:11:31 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 22 Aug 2018 04:11:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paquier.xyz; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=O1IoQDsc/1t6V+H1wQFrvD8o/wWBVQBK2PHUKYShcVk=; b=VpWZx3D4 737Kfqc6ZX6Wc1ubz+kispkD0JiFCthy+DIOAtOLXOUUzys/Ovnyc6/5yqoOBiGx W0FZMtFcNvJn9X2lKIAkUWDJaxqU32Dt5TvkqMTvhtaa0dXPThk+Z/lF13TjBpfD 7k0JQ5RE6oqyW3sn2Qmir1Ay6mkE3kGNo+AgO7hq4Pk+ElwWVptSn3BbbaQpaKgD 5ejxdHEn4pDFG5T9VxjgHU3v+4dYUNKUAFpi+W50b7huFGpNu49C51YRD6taN82h nY0s5S6X53zjlJtXg9FOaJweMzI5daaTczL9bNYbCIzg5DIEQyNSEjyDaEYveBOv XPlQzB7fI7ZUFA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=O1IoQDsc/1t6V+H1wQFrvD8o/wWBV QBK2PHUKYShcVk=; b=QN8XPYddM1PBDj/M0uBn+Xx2npK4lWxnnm3YgQEUcu5Xt HX96fo/7qgfsqWQ2vm0EJtypzyO26CiEuwCUksmNSn8Y5W9byxBlnRww5Hr6qB3q yqjQcz1eRSS3J0RBKO+W/K+VH5rV0hBJ2//9I37ub+cWkT2kOjhUnVlOywIzrwZN ssAJoRcvsJ7mhvNJMSO6pbPflxlqclhKATKZW4z4REvVqZCG7enO6UtiGMPbsXOn 5icQ3t9wWOLhbCbx8oSNIxGHyHFkBdwG4R+Ke9nDQaU1zstyQ5X3QDCivIS1sgZi /th60GYvlEbq/SLhueJj+je8NvfK2EOINmbNPwMAg== X-ME-Proxy: X-ME-Sender: Received: from paquier.xyz (c137162.net61215.cablenet.ne.jp [61.215.137.162]) by mail.messagingengine.com (Postfix) with ESMTPA id 3BD9F1028A; Wed, 22 Aug 2018 04:11:28 -0400 (EDT) Date: Wed, 22 Aug 2018 17:11:26 +0900 From: Michael Paquier To: cyberdemn@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #15346: Replica fails to start after the crash Message-ID: <20180822081126.GE4333@paquier.xyz> References: <153492341830.1368.3936905691758473953@wrigleys.postgresql.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="n+lFg1Zro7sl44OB" Content-Disposition: inline In-Reply-To: <153492341830.1368.3936905691758473953@wrigleys.postgresql.org> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --n+lFg1Zro7sl44OB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Aug 22, 2018 at 07:36:58AM +0000, PG Bug reporting form wrote: > 2018-08-22 06:22:23.633 UTC,,,54,,5b7d0114.36,23,,2018-08-22 06:22:12 > UTC,1/0,0,WARNING,01000,"page 179503104 of relation base/18055/212875 does > not exist",,,,,"xlog redo at AB3/50323E78 for Btree/DELETE: 182 > items",,,,"" > 2018-08-22 06:22:23.634 UTC,,,54,,5b7d0114.36,24,,2018-08-22 06:22:12 > UTC,1/0,0,PANIC,XX000,"WAL contains references to invalid pages",,,,,"xlog > redo at AB3/50323E78 for Btree/DELETE: 182 items",,,,"" Once recovery has reached a consistent state, the startup process would look at if there are any invalid pages tracked in a given hash table and complains loudly about them. It is not the last record or its surroundings which matter in case, but if this page has been found in one of the records replayed during recovery up to the consistent point. Do you have in any records from the WAL segments fetched a reference to this page? A page is 8kB, and the page number is 179503104, which is definitely weird as that would cause a relation file to be more than 1000GB. If the record itself is in bad shape, this may be a corrupted segment. As far as I can see you only have one incorrect page reference (see XLogCheckInvalidPages in xlog.c). > I will keep this instance around for further investigation and would be > happy to provide some more details if you need. That would be nice! -- Michael --n+lFg1Zro7sl44OB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAlt9Gq4ACgkQnvQgOdby QH2pSg/+Ilvhm+YRTDDEQoLzw7fvS7AkbfcUe7QLbxQbtFCFcIqKcs8Msvk8szpG WMDLIbq8pbHIGsQ9X1rZOMoSwkYPFoTAyDGx90nF+NsxqhjQiYVtxFA+BomA8/3h JmlTACLTAzCaj+KVDGAdPKA3UrAi0A316HveJYwW177WlJlZeHy1A2rxUrgCzQuS r8k/rpuNskBpSiaj4s6Q0YYBHL6wdyUIZu/C0T2euOVqmZIASx7xSfk60RN7eCsw leV1R8CSecXNxJpHS0lJj/h4/Y5Qk+bmNk8csL+gta8n6xfLP3cIrxJY8PyTHXDm y5XLoy4xZry49skhTGmsmCBXVKSAn968xFxMYewfLUSzSpS+75ixDr8R+iiI9mmH w/PchifysG/KpzdkDDr0AKHPEuTLtGxDds81+vvFelvxEXmBqEbGZhJ2gnOf+4di 3IpLjwfsAE0vCmo9EoMOdN/mFZ1FycmbVa3iJmN/bS1Xvmk943gUjeK9h848y0Hh S/lh8Gt7a0dlub6YVMDZ0wfo+gwq49LV/UMVH/bN9Pgv124ZzumwM3gLlGy8Fn5H G++qfo5JQnhnE2G6hN1sC2zAR9TAEgtQ0tPQIvablKz3ouW7i+uiiR4h/agM9Z/2 Og9YXTpr/+0NaTpZD1S74Ee+wOy+h5rQcR9AbwmhQVkUQf1aIl8= =5H6Y -----END PGP SIGNATURE----- --n+lFg1Zro7sl44OB--