Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j1kZb-0006v8-2K for pgsql-hackers@arkaria.postgresql.org; Wed, 12 Feb 2020 05:28:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j1kZY-0005XP-Sl for pgsql-hackers@arkaria.postgresql.org; Wed, 12 Feb 2020 05:28:28 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1j1kZY-0005XI-Jt for pgsql-hackers@lists.postgresql.org; Wed, 12 Feb 2020 05:28:28 +0000 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j1kZW-0005t8-CS for pgsql-hackers@postgresql.org; Wed, 12 Feb 2020 05:28:28 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 1B59148C; Wed, 12 Feb 2020 00:28:24 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 12 Feb 2020 00:28:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paquier.xyz; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=oxBkb9q6WypouOCuC9V5HkNeCts WMEKAzLX2bVrjlMs=; b=GIxnyreT6bX8VcWK43t+KrPpRZvB7TdRy+ALxgu/ZTg EAbfJ4m5umtfFhCfcYfUtdCrrrvTn8dJGeK4N6WAFmyapsWfaSqcdXy/5LVJe5bu zxKEoPpNNtTRjmkdJdxsbcYBI8iQaR5iM5NbHVNvNEbstchaKmCtPugABbBxiOrd qtjSmQeEBUX/vxp+CqiqNtYGeR2Tv4NDKskO5dgICZnmmNVv8ceNQ4kbAB8fCEKV 4UapNrBpIA2UGD7xZ5AR1g3iqBU/SzpNZHBpZJlQtSewxtiAqRJhN1pK3TCJPy79 HG7K7jxjq7oNcPBTvTNAsJmxj2ORX8SpJ47rnb/zHVA== 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-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=oxBkb9 q6WypouOCuC9V5HkNeCtsWMEKAzLX2bVrjlMs=; b=TTNxYvoHaHLd/vwXR6rK+Q waOHbo01yXHl6Ad7cwdApEmJZftlpJSD8l3pVeid/F3jcXxO3mDN1w3PqVi4Y5Ib ca1v/09SKIo94qoJhrjkdjENxlfiOWp8ytHSJ1DeXY5RsVzzPGXSJEQAZr/Kr+zl ORMCiLIxGZFYwNM+pEhcb4j3WdznjMuEydAl8LLPPDXX7z3glf6yQAo114fvrVW8 UCZ1sCcDpF6jbGo/wX0mq9zoGsGClM0FqNrWsPC1wIbV+oWaFvloUkpPQaT6eHmR 1xHtujYG/frk4rvFhZjuKbOrlkf0as9qF6kX5ztH67pkKYg5W5sUdCvlyW8ubzEw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrieeggdejkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenfg hrlhcuvffnffculdejtddmnecujfgurhepfffhvffukfhfgggtuggjsehgtderredttddv necuhfhrohhmpefoihgthhgrvghlucfrrghquhhivghruceomhhitghhrggvlhesphgrqh huihgvrhdrgiihiieqnecukfhppeduuddurddutddvrddukedtrddukeehnecuvehluhhs thgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhitghhrggvlhesph grqhhuihgvrhdrgiihii X-ME-Proxy: Received: from paquier.xyz (ee0822lan1.rev.em-net.ne.jp [111.102.180.185]) by mail.messagingengine.com (Postfix) with ESMTPA id 39D003280064; Wed, 12 Feb 2020 00:28:22 -0500 (EST) Date: Wed, 12 Feb 2020 14:28:19 +0900 From: Michael Paquier To: Peter Eisentraut Cc: pgsql-hackers Subject: Re: client-side fsync() error handling Message-ID: <20200212052819.GD1464@paquier.xyz> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ycz6tD7Th1CMF4v7" Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --Ycz6tD7Th1CMF4v7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Feb 11, 2020 at 09:22:54AM +0100, Peter Eisentraut wrote: > Digging around through the call stack, I think changing fsync_fname() to > just call exit(1) on errors instead of proceeding would address most of > that. > > Thoughts? Doing things as you do in your patch sounds fine to me for this part. Now, don't we need to care about durable_rename() and make the panic-like failure an optional choice? From what I can see, this routine is used now in the backend for pg_basebackup to rename temporary history files or partial WAL segments. -- Michael --Ycz6tD7Th1CMF4v7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAl5DjPMACgkQnvQgOdby QH2FDBAAp2CFkK+CJUDRbo0tFyOEFUcv0UBlsP9SbZJch8huT8q7FjJWX8OtzEQI BGx7Jm+ftasf1JydzaRwiAnquMqvlV50PWoGIRsxiw7Do9wU5hkjlLPgJYaNcPcV rWTXAlvhe5UwdatrAiH2t+KKUjYxiHAJyjKkb+gslbv5Rf/KGpBrqQgfilaVCCL6 WQhCMN3WCd4vPeIPT1QZN8gbc5bs90KJ81zwYn1UwD5sIvL6OYs99RwkthUvp35C d5NX+b6T8ESdQDzHnDizI6KScJUKRkoeDweTaO3SU2b04horpYWhffszpbwNqm53 zWSau1jQBg3eTFqw6inRtZK3vDBPy3+uYPzFffAgP6FTBkUMT3dySjWSWGRsJoZ9 6mzwAmHrEd0YA2PU6/k+JoXBEmz2wm7DFbifqODACai89ADyvkWgzJGbJFQbv44N 3uFQ29wccOodAoldQmtOD3PnJbCj8YjtY/Xr0otEmKbzElrkwgSVDbCydzcVipOi F+DUfgNEYadNhGsSfk/vROpOf4/GgxboTfwwiKHpzWlQCzbcEl7uD4Ixx1sB++0F k8Ksed6txv9T6SP61NHdC6yA92IZvZj/ow1D7MA7Py8aEjiJRrACeuYhnt643/A8 QOyCkt0pNb3C0ADioUYLlNDtcUP/dHtzOkniKdfqsWjbuhKpTKc= =7qPI -----END PGP SIGNATURE----- --Ycz6tD7Th1CMF4v7--