Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f0jJf-0005GJ-Ao for pgsql-hackers@arkaria.postgresql.org; Tue, 27 Mar 2018 07:46:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1f0jJd-0006tg-V0 for pgsql-hackers@arkaria.postgresql.org; Tue, 27 Mar 2018 07:46:45 +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 1f0jJc-0006tV-Bi for pgsql-hackers@lists.postgresql.org; Tue, 27 Mar 2018 07:46:45 +0000 Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f0jJU-0007AB-GM for pgsql-hackers@postgresql.org; Tue, 27 Mar 2018 07:46:43 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 3CE17207B0; Tue, 27 Mar 2018 03:46:35 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 27 Mar 2018 03:46:35 -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= fm1; bh=5q8ytMEm7T7nt4vva8rhl9Vjes1pj5lUWnjbIwAwBCU=; b=yRpbYiri dCTYOaAsmJtCZTZa/CBscbXuTr6/bpo0PuEJyyPY53rhRLO7QWln1JzONYSWf/vA eARuGa+EzergYjYlE3u+30Gx2e8O+FfdApllrgcu08i8F45Z+MrQioHnFKezNI6d 5CoNNyPpMVw85BdRQi7XB7xYXpAfUdXteaj44wa5mZsph8mPOWXlCGjlfuSG+GI/ 6pZqOOlkKIqO93ik5TDqjMV9D3k4yM11KMwo8D2Ic0ukm9TdHgctvNpgXkCO4Fek BjlaqhjPYwSX6WC2SzRDOE0qVrm0Njwy5TR2FsVomAgcAJHXkeGxSzSSFcEiTSpz /duff4dC9y1R2g== 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=fm2; bh=5q8ytMEm7T7nt4vva8rhl9Vjes1pj 5lUWnjbIwAwBCU=; b=UC/AEMnoAdmdjttacjM2SKEJybVr+Bi3XfWUPlVBU/PSz XzjTKZz0hoI/Q22BMwm9IjUkuslNL4JgclCb9m8zHNhVwtZmBIkgJYAiBBTUhjDm ssMriWpJEZuCjAb96Zqg/8zrvqeOxEOyaKcSRrhJGvzOhgkuz+Emx2K8LSpxwvCz 10I/CCthMypvK2UToRdHaDopua2zY4UxvyOhZ9NuVvaAkMtz3fhzilg+BtYVn3iM +pdTA00qPDN/AaDFTUogm3+3A5wLXR8PfYNd/xzoUnIDQWc8MNbwIRJftarkVc46 BnIoIACT48imGPYpAwK9jdXrjaqh7JT7T1eaB6JAg== X-ME-Sender: Received: from paquier.xyz (c137162.net61215.cablenet.ne.jp [61.215.137.162]) by mail.messagingengine.com (Postfix) with ESMTPA id C4A2A10255; Tue, 27 Mar 2018 03:46:33 -0400 (EDT) Date: Tue, 27 Mar 2018 16:46:30 +0900 From: Michael Paquier To: Dilip Kumar Cc: pgsql-hackers Subject: Re: Problem while setting the fpw with SIGHUP Message-ID: <20180327074630.GD9940@paquier.xyz> References: <20180313080404.GE23071@paquier.xyz> <20180316052354.GI2666@paquier.xyz> <20180320055608.GB13368@paquier.xyz> <20180323074956.GB7070@paquier.xyz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sDKAb4OeUBrWWL6P" Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --sDKAb4OeUBrWWL6P Content-Type: multipart/mixed; boundary="ILuaRSyQpoVaJ1HG" Content-Disposition: inline --ILuaRSyQpoVaJ1HG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Mar 26, 2018 at 02:32:22PM +0530, Dilip Kumar wrote: > On Fri, Mar 23, 2018 at 1:19 PM, Michael Paquier > wrote: > In StartupXLOG, just before the CreateCheckPoint() call, we are calling > LocalSetXLogInsertAllowed(). So, I am thinking can we just remove > InitXLogInsert from CreateCheckpoint. And, we don't need to move it to > bootstrap.c. Or am I missing something? I have finally been able to spend more time on this issue, and checked for a couple of hours all the calls to RecoveryInProgress() that could be triggered within a critical section to see if the move I suggested previously is worth it ot not as this would cost some memory for standbys all the time, which would suck for many read-only sessions. There are a couple of calls potentially happening in critical sections, however except for the one in UpdateFullPageWrites() those are used for sanity checks in code paths that should never trigger it, take XLogInsertBegin() for example. So with assertions this would trigger a failure before the real elog(ERROR) message shows up. Hence, I am changing opinion still I think that instead of the patch you proposed first we could just do a call to InitXLogInsert() before entering the critical section. This is also more consistent with what CreateCheckpoint() does. That's also less risky for a backpatch as your patch increases the window between the beginning of the critical section and the real moment where the check for RecoveryInProgress is needed. A comment explaining why the initialization needs to happen is also essential. All in all, this would give the simple patch attached. Thoughts? -- Michael --ILuaRSyQpoVaJ1HG Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0001-Fix-WAL-insert-when-updating-full_page_writes-for-ch.patch" Content-Transfer-Encoding: quoted-printable =46rom 0fc3878375890aef5c0a6dc57d73c30aa97c88df Mon Sep 17 00:00:00 2001 =46rom: Michael Paquier Date: Tue, 27 Mar 2018 16:38:37 +0900 Subject: [PATCH] Fix WAL insert when updating full_page_writes for checkpointer At startup or when receiving a SIGHUP signal to update its configuration, the checkpointer may need to update the shared memory for full_page_writes and needs to write a WAL record about it. However, just after a promotion, there is a small window where it is possible that the memory context in charge of building WAL records has not been correctly initialized, leading to a crash of the checkpointer. With assertions enabled, this causes a failure when allocating memory in a critical section. And this fails when trying to build the FPW record without assertions. Report and patch by Dilip Kumar, reviewed by Michael Paquier. Discussion: https://postgr.es/m/CAFiTN-u4BA8KXcQUWDPNgaKAjDXC%3DC2whnzBM8TAcv%3Dstc= kYUw%40mail.gmail.com --- src/backend/access/transam/xlog.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam= /xlog.c index cb9c2a29cb..aae1131977 100644 --- a/src/backend/access/transam/xlog.c +++ b/src/backend/access/transam/xlog.c @@ -9543,6 +9543,16 @@ UpdateFullPageWrites(void) if (fullPageWrites =3D=3D Insert->fullPageWrites) return; =20 + /* + * Initialize InitXLogInsert working areas before entering the critical + * section. Normally, this is done by the first call to + * RecoveryInProgress() or LocalSetXLogInsertAllowed(), but it can + * be possible that this has not been initialized yet for a checkpointer + * which updates the value of full_page_writes for a received SIGHUP or + * at process startup. + */ + InitXLogInsert(); + START_CRIT_SECTION(); =20 /* --=20 2.16.3 --ILuaRSyQpoVaJ1HG-- --sDKAb4OeUBrWWL6P Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAlq59tYACgkQnvQgOdby QH3QDQ/+LDPjDOakS6NnfiiSoMwMR3PeFycAMiyRUXEP/dR9TrdJR1DRFNNtrOQW qPIEEU65IgKpQ/ktSCdEVLh35mvOzHLNBtnI3+03zj9KwBTx6a/Xtrz09fX7RbDM WyRZUzPrb//SB0Tibgcmj2t9GZMs96RGHWR5mPjsdVNpTHOgX5EQlHFu+9EInWLd LUj02jsvWj3CkF9w8ahhMXpaK7aPgFVNCoi6LYnQSQhEp6R8Qs945L36zOT9C8Xd TvGRWrLl9rGq1nGy3xx20eYBgmc8hVlr9p0jxWvZL7Yc1klzoJW9NolKba7PKiMG b2v4GDfwftXvY7dteXuD5MSaRdYF2Du5rjUipThv7IwVIDsNgSLZ4fq7gK62j0fo O9ptwyJbAMzt71aGJ3sXTJqomH55d2WuvgqdXW4wHvhm+RmSPGrOR5tY9siOnm2Z 292dLNMfxY3XDkXdF8RGhNkj105sQpByFbNCaUtYsIt9HM6/jDvcQD2NEE9rrjYX 9+Dubpz+OaHltG0qSAxnCDbdTbcE0hIdcr6OT6qQHyFBm3+0KSuWXq5CjQcqyH2U xMBzQKnnzSHYy6FAwHup8L2eqOdI6XBTgKMJrNFQw8cvEwFK5mWVCPxq1SGa9uWs ojPFWR1WPAH+AmOF2q5fMrWcPgnqax97LC8nBG2AAhTKpdkqdSY= =u/1z -----END PGP SIGNATURE----- --sDKAb4OeUBrWWL6P--