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 1eslzq-00025p-Bv for pgsql-bugs@arkaria.postgresql.org; Mon, 05 Mar 2018 09:01:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1eslzp-0005Xn-2Z for pgsql-bugs@arkaria.postgresql.org; Mon, 05 Mar 2018 09:01:25 +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 1eslzo-0005Xd-HD for pgsql-bugs@lists.postgresql.org; Mon, 05 Mar 2018 09:01:24 +0000 Received: from new1-smtp.messagingengine.com ([66.111.4.221]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eslzl-0003TL-4o for pgsql-bugs@postgresql.org; Mon, 05 Mar 2018 09:01:24 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 13032139C; Mon, 5 Mar 2018 04:01:19 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Mon, 05 Mar 2018 04:01:19 -0500 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=j5TOfSl3tUU/CQe1rouyKq3dQ8AjaEYQh4s4NrcDOus=; b=ib/fgXKs SjsXxfp2doCduviZK41uZ+mU8LrqWnFf2W8nmQv4RoJ7IeWV0jjpPMpBVWRw+LgY vIsh3oNZ6DZ0Aa1QJort4/qUvcYhZ0J1gAGfOICoF/MjDUe9CrLHrQXBqvbBe5d7 /z6JX9NTsMjTwAwugd+oW7H3ZU/KVxWg+r6pMjS2nDry0QICNPT/AibFtgr4IQxz tGvp/bOvS6jd6VCkYqp4vxP56VUO+rSXQr5eRsT/STXpiz8yJnLg90fLsM2hMRfO 0HdQ7ldFhk+dCi3r+GLF+w3dGEL/k7OHkm9gpOx9rsxs7TA6KaIJro3QiiFjz+uS O0m0ZOJbOLR3SQ== 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=j5TOfSl3tUU/CQe1rouyKq3dQ8Aja EYQh4s4NrcDOus=; b=Y/8gi6DML0DmrktxKfNbVhgXYhutRA/MoYDo5iRt+ZbGV fGsDZngJPed30nFZUolk0m8XwQcd4f1ZTVUHJyddu9RNVe9hERicK76rYPRuOSQb 7eyCVyxI6q9TWmC/Xz6KC3BtvbgrLoMjAlYatHfvEwZkum/N4XM2DMzv6hTPRJ+x yHJoJE3Eag1gz5mLmFFYKtH3+nauXY/bOpt1Q+zo744bL925RPBOLIE0SdVGhPEg doJ+lQCtS6DOr9KRTQVRDKLVfee8b3I1CbwZ+i8qb1Yvwr1dgn4RXUod1w9BxrIF wOg1dYRQgvjlJUUjDAnoSc7UJ0NHdW+bXjx/3uxkg== X-ME-Sender: Received: from paquier.xyz (c137162.net61215.cablenet.ne.jp [61.215.137.162]) by mail.messagingengine.com (Postfix) with ESMTPA id 6E6DA24880; Mon, 5 Mar 2018 04:01:16 -0500 (EST) Date: Mon, 5 Mar 2018 18:01:11 +0900 From: Michael Paquier To: Masahiko Sawada Cc: Dmitry Dolgov <9erthalion6@gmail.com>, TipTop Labs , Michael Paquier , PostgreSQL mailing lists Subject: Re: BUG #14999: pg_rewind corrupts control file global/pg_control Message-ID: <20180305090111.GI2266@paquier.xyz> References: <20180104200633.17004.16377@wrigleys.postgresql.org> <0D104D1E-6103-49F4-8AB8-B5CD92949E18@tiptop-labs.com> <20180115072537.GC1724@paquier.xyz> <20180227012441.GB3255@paquier.xyz> <20180305075431.GH2266@paquier.xyz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="zH41lVBEV8cLJnCl" Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --zH41lVBEV8cLJnCl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 05, 2018 at 05:47:06PM +0900, Masahiko Sawada wrote: > Since files other than relation files such as vm, fsm, WAL are > categorize as FILE_ACTION_COPY_CONFIG, I think the name would cause > misreading. For example, we can use FILE_ACTION_COPY_DATA and > FILE_ACTION_COPY_OTHER? I am not stopped on a given name. > As you mentioned before, with this patch we end up ignoring file-open > error of database files other than relation files. I guess it's a bit > risky. We can enter them to COPY_DATA but I'd defer it to committer. COPY_DATA is aimed at being used on files which can be parsed by blocks. You cannot do that with VMs and FSMs. Now you are true that we=20 could complain for non-configuration files which need to be fully-copied, still Postgres issues a fsync on all the files of the data folder when beginning recovery, so you would bump on problems anyway after restarting the rewound instance. -- Michael --zH41lVBEV8cLJnCl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAlqdB1cACgkQnvQgOdby QH1Mgg/+OVIXXLrco/7sE+KfcRJleyegHz9JSkHgyo1Xn6+AuRvP+RBJG4qt0eCx HJwWV2eCGqP7mGHJMaBaoaIFlV1dFmcgQ5fzu4bw3yArqzAFTfcxbyrvO2sQtAQ+ r+JnFMO4lCG9r/zOVWfKH2e3WYiGUTVc550K/DjyKawsLuwc7PfK3NopmSa4iVRH pHpZilIRibHXPcjc4XjgIgX1uku/ok9U+C7l0AEScfrUd8JE5Tc9uZF/1YCayOUY N+IHHnxmrAXbFoFqDFA7QZhRZwPyrfUG3YWCjYlkwH7FBaWJuI8f05fvRM58osut SKaFDxoSJLNP8oGetNtd/2f2SVbYiUz5xkihmoNIfDzEIqYE7h6ittnQUt3m5Svr hrKCuwiCac5Az2OCyTVjjvMKmxOMW+sIt7DwsjmWXtHm+tsrNUL+bSugv7NKMQCc DgKqCVzCNJukRD7MDQmtIQr9kxqVW3XK3JAECM0UtmuBpk6ZSg7k7KByxslJ6rmn k/bRXG/SxUtGwb/6XKqHDs0q3SFVUYeFtXLW5Tg9gpl7HDQ3nNLN4nvsRU3Tee3s b43z7msO/T0DeEVwnZRbpZx3399/p4Jrq5g+ICZ0qizLT/Znla5R9Ms2ZykiYIUd avNwns3EhZUL4BWl7oILa6tQ2JAlhNqZnVMlUJSZiCRkDE64iqI= =9/qn -----END PGP SIGNATURE----- --zH41lVBEV8cLJnCl--