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 1fvcr5-0000mD-BX for pgsql-hackers@arkaria.postgresql.org; Fri, 31 Aug 2018 06:24:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fvcr3-0003Os-1y for pgsql-hackers@arkaria.postgresql.org; Fri, 31 Aug 2018 06:24:25 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fvcqn-00025R-4w for pgsql-hackers@lists.postgresql.org; Fri, 31 Aug 2018 06:24:10 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fvcqh-0001Sx-DC for pgsql-hackers@postgresql.org; Fri, 31 Aug 2018 06:24:07 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 5CF9521F37; Fri, 31 Aug 2018 02:24:02 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 31 Aug 2018 02:24:02 -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=1bOCeU+TbQVfgkiSMlhy53UIll8BWDaXdwZHGTXplFw=; b=wmiQC0O8 /KgAgRmPNTqn6j/tCzjEQDOg7pjYpz4Twfx2+Ha8rcydk7Mm88MCUenzBh3n9HDb keZ5Nb36NSvjLbegx2R7SX5lOc80bog/iPy8udDSj6+62EDJLZltRRzFSg8rM+vZ 3Bk+4++hrhIGl6HoUM3uVw34uV34tIDR9P/OhV3eZVixUZbgSDGJ1mtRWfpfxPXT EoTDVtv3qZWajiV1u92sG/o3Pae2HXCcZGdrdN/0zu2d9porDGW63jEW4fk42SF7 9f8GOd0DoRZEcx56zobohv0mFYrDlOkwXj8Bgz2CSL/b7+p700lswOnIIEnIHRH5 ToBHTfmIF4qg8A== 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=1bOCeU+TbQVfgkiSMlhy53UIll8BW DaXdwZHGTXplFw=; b=WF9we1zqaInRwmlsUDFY9ShbOmL8vdE8Rmp1C64jQpVqn yxo1nZ18+EHeoGUqMiOwHff4MNejNrN6rpqscyBz+xsmBUpCc7NJMAM5/XOBi3+0 HmIHzcx5/9Tlyed9tY8IJGBYCX85RtDDv+H+WCX0mbFJ+cT3S3q+3Yw181c/t5kX vXlFaWrwB2UNbGVkd8Z8i0s30qs4qLTaOeRuKdxFUou1iBv6YjP+MqYH7P+6VgUb OgN6IPvnDUphHN+bOF43btjQIi3MvSLZ0ABhTAFOdJGMhtRJhjUXfr0TuntdEdpP x/7YF9robewkk17owrXOPz/pTkdgiA7zttoHHpmjw== X-ME-Proxy: X-ME-Sender: Received: from paquier.xyz (unknown [66.201.48.83]) by mail.messagingengine.com (Postfix) with ESMTPA id 81134E442E; Fri, 31 Aug 2018 02:23:59 -0400 (EDT) Date: Thu, 30 Aug 2018 23:23:54 -0700 From: Michael Paquier To: Kyotaro HORIGUCHI Cc: cyberdemn@gmail.com, pgsql-hackers@postgresql.org, alvherre@2ndquadrant.com, 9erthalion6@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #15346: Replica fails to start after the crash Message-ID: <20180831062354.GK15446@paquier.xyz> References: <20180830185705.GF15446@paquier.xyz> <20180831.094846.52751456.horiguchi.kyotaro@lab.ntt.co.jp> <20180831014855.GJ15446@paquier.xyz> <20180831.145206.05203037.horiguchi.kyotaro@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LvAn5G4Ewe70kJ1i" Content-Disposition: inline In-Reply-To: <20180831.145206.05203037.horiguchi.kyotaro@lab.ntt.co.jp> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --LvAn5G4Ewe70kJ1i Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Aug 31, 2018 at 02:52:06PM +0900, Kyotaro HORIGUCHI wrote: > The patch inhibits turning off updateMinRecoveryPoint on other > than the startup process running crash-recovery except at the end > of XLogNeedsFlush. Yes that's a matter of safety, as I put into the truck any modules which may use XLogFlush(). And that maps with the old code, so there is no more surprise. > Even if any other processes than the startup calls the function > during crash recovery, they don't have a means to turn on > updateMinRecoveryPoint again. Actually the only process that > calls the function during crash recovery is the startup. bwriter > and checkpointer doesn't. Hot-standby backends come after > crash-recvery ends. After all, we just won't have an invalid > minRecoveryPoint value there, and updateMinRecoverypoint must be > true. Yes, until a recovery point is reached only the startup process could call that. Now I would imagine that we could have a background worker as well which is spawned when the postmaster starts, and calls those code paths... > + /* > + * No other process than the startup doesn't reach here before crash > + * recovery ends. So minRecoveryPoint must have a valid value here. > + */ > + Assert(minRecoveryPoint != InvalidXLogRecPtr); ... And that would invalidate your assertion here. -- Michael --LvAn5G4Ewe70kJ1i Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAluI3voACgkQnvQgOdby QH3uCQ/+IfpSwIGp2Fqat8cz4DLUfFY7zk0F6vdpQ2jtPY5S1lv+XgFt2dWChwFC OhhmHnNynoAlbNHBxXoYnwpN9IyIS8VD3u/XJTqUHQQKFxVTKAmTZUjs2U4V24n9 Y1FryEdbkk0AhTaQDHHZCZ/BTfc2gLwaEcHgeug7io0dK4jWNtQnZtXfqySsdexG yiU5GCk+Yo5b4DPGoxYLrPgNDQxv8UqnTJIdr6QoROLNGFELSUfDlGFtF0qSfnIw erEuo2NR15t9HuFsTPYOYgQO9DpqgP+Ovd9dOwxJou9JIUheUuBNDLSJTbUYKR5u cHBzAaYEUgGiGVLoJRD0tFtz/x2BBoki9X+3BLyvovrumacppRAvODv/iyq7pEXv umXkj4lp+6HCQvx20iZxYWZE2yBRfR2Zi+r43d6lGMKwHxEvCSWwPj24KsT8lTmL 30TzPw35iZtg5Ed1k2czaxGDgKytw3nlVv9WWeid9wG3gklh/3vzqcQbjFeLwg9z BGXNEjj9PGoOc6QG7oWrodt8ieKIBYMBIOfY0gGLQPAjWs0oO4b/X1kT6LmS7dAV qRis5ph0nGss2/ZHX4TUmcZq12ZBcl2I3dO6LOS/COShIZF+eRsQ9qwvydAJa+Oc A/jz3a0T4MZnhKe49bI2SkEWaM1WqHfsM30AzUssF7zCI3ziZ54= =MVaJ -----END PGP SIGNATURE----- --LvAn5G4Ewe70kJ1i--