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 1fsh19-0000Tq-JQ for pgsql-bugs@arkaria.postgresql.org; Thu, 23 Aug 2018 04:14:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fsh17-0005jd-V9 for pgsql-bugs@arkaria.postgresql.org; Thu, 23 Aug 2018 04:14:41 +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 1fsh16-0005jW-Gk for pgsql-bugs@lists.postgresql.org; Thu, 23 Aug 2018 04:14:41 +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 1fsh0y-0003A0-Tb for pgsql-bugs@lists.postgresql.org; Thu, 23 Aug 2018 04:14:40 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 51D4821F3E; Thu, 23 Aug 2018 00:14:30 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 23 Aug 2018 00:14:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paquier.xyz; h= cc: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=uzhvgCYhid+ZFSNRvRqkIRtpqHzgFatlomrCm0IdBmU=; b=oK+ENfBC oX3CdbK4lX3lwgASUcDa7Yad3tSVMSB8jw0JF59yefCiC0zueSPBvkFi7/9LKU9j R6uRy0ptFe2S2OEaWeUlUXzG3zbEOHyZgOMWrMG6zO0Cv4p2CQnLhAUndbw8ER7c lweA8wNWNhRLWoD7hf4TR1XdGTs8JaWiwEXtDUgdl8xNAKj+HcXzoaHetF3c84nR GYYgBCJD6LkvQIW870MnARMBAmmyYMxBHmZ+TPIKG+1EbBjovgKE+S4MOzG981dw zNDJGnABfSPimtSxUo9/1V7+xMcgjGYjCsW1ijdGSnyP+Cf79yMUMbaBPwUulgmA tzi14meMUcGP5A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=uzhvgCYhid+ZFSNRvRqkIRtpqHzgF atlomrCm0IdBmU=; b=Gt9y5ho/LWgJuVliYMr4rTDg+ub9lWmGWX3dUd5hwIIXl 3xF5g0ifqDyETKy305cUHM5uDD+pkFl8eW4fEKPCFJbMrCEvxk9ROaowoPXI6Qtr qu3FPMzVAUipvHMLO35XEzWJW/vWG1x1qG2/mQpQPHRrvaeqNvOiw4c5LWdMK7hN RcVvTB/IN+/ZueivZ5fvdrHbPIzy/YhH50zPRQSz2jg20mXYg83EoyS8mbrQkH+e +AVWey25su/Il/JG6HZhAi2AR1n2w0FdWuFxu35O4cusqoB7a58NbS4D5INQL14s 8EJvMVXHQLnHTjLNAPge2CL99tt6gdGybPKDdyNMQ== 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 E847F10288; Thu, 23 Aug 2018 00:14:27 -0400 (EDT) Date: Thu, 23 Aug 2018 13:14:20 +0900 From: Michael Paquier To: Alvaro Herrera Cc: Dmitry Dolgov <9erthalion6@gmail.com>, Alexander Kukushkin , pgsql-bugs@lists.postgresql.org Subject: Re: BUG #15346: Replica fails to start after the crash Message-ID: <20180823041420.GA1158@paquier.xyz> References: <20180822175034.lnvwk5js32k6mjyz@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline In-Reply-To: <20180822175034.lnvwk5js32k6mjyz@alvherre.pgsql> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Aug 22, 2018 at 02:50:34PM -0300, Alvaro Herrera wrote: > On 2018-Aug-22, Dmitry Dolgov wrote: > I don't know. I was thinking it could detect some invalid write in > shared memory. invalid_page_tab does not use HASH_SHARED_MEM. What did you have in mind? On my side, I have been letting a primary/standby set run for a certain amount of time with the following running: - pgbench load on the primary. - background worker connecting to database, just running in loop and sleeping. It uses BgWorkerStart_ConsistentState as start mode. - The standby gets stopped in immediate mode, and restarted after some time to let some activity happening after the recovery point has been reached. After close to an hour of repeated tests, I am not able to reproduce that. Maybe there are some specifics in your schema causing more certain types of records to be created. Could you check if in the set of WAL segments replayed you have references to the block the hash table is complaining about? -- Michael --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAlt+NJwACgkQnvQgOdby QH18Ag/+M9Lhsrl1RiMij49AA+Y47tbAjUjnZ+U/SEPahv7pfBCAjMzc6dhHAM2U JCeXKYeE2tSVJ3N+NyfscA3lxNpcKUNGZmjPhrmt61riIYCvh5XFxnni3AApbjXL skkE1I8xbTOgwW4BRzXZM5DGp3dHp9o8M9u7rYrWD9ZePrjoj6Nx+VhcouHbEo6T aLNI5xWzhCisHX9XSUQEebhAJ+l0SPd4EX4cgDPLS761Rcushh7xTDynTp7M3WVM d33pocC597AIFpy8d+Jpm11cQ6RQKXGnkty07fn2Onz3GNs+aKdlsub0b/J8pzgC TBQi6RID2HCFXutuDjVSc/BUMCZYEjxwZ655dkF/W/ooRt9npy6/eKFfC1de/AIa L4+TYjtqUmwK5iZWTvQSzJLv+akdXU48apCHN7+6pIPg9mpLrJJ2pYEfLD9t3W5u 0ePm94dGZ3f5TZGTJf/HfY0KKgG21nKnNXhKwyQlHQbWYnwu6pfr95fvMAQl87tP DkZnUTRfjcXnmRzqF/hkIocqdsB79qmR3fg62JmoKZ/fze4DMjVQhP1yX/u6BNf3 ddnxjdy3CkrQI4BkVy3a8QXoKf15y/aEtwaUssVm/cBvDK+p7EaMaltiVYRCBBe+ bV5yzMTiqJBuGdI9z/lIgCpPJnyR8EuEUX7TizZ6ktf3FkPoXxg= =ZaDe -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV--