Date: Mon, 18 Apr 2022 16:48:35 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: avoid multiple hard links to same WAL file after a crash
Message-ID: <Yl0X0+/9lcGzcIui@paquier.xyz>
References: <20220407182954.GA1231544@nathanxps13>
 <CA+TgmoZ5VHuv_BzpH7jrgyLu1Kymo=Xom5xFOeGf6xXP9BLhkQ@mail.gmail.com>
 <20220408165312.GB1409034@nathanxps13>
 <CA+Tgmobjke2TBrYk=Zmo=zawkG9A4saAwbe-O5wLHqY9Bz1Fag@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="8hotg91fg1rYekFA"
Content-Disposition: inline
In-Reply-To: 
 <CA+Tgmobjke2TBrYk=Zmo=zawkG9A4saAwbe-O5wLHqY9Bz1Fag@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/Yl0X0%2B/9lcGzcIui%40paquier.xyz>
Precedence: bulk


--8hotg91fg1rYekFA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 08, 2022 at 09:00:36PM -0400, Robert Haas wrote:
> On Fri, Apr 8, 2022 at 12:53 PM Nathan Bossart <nathandbossart@gmail.com>=
 wrote:
>> I think there might be another problem.  The man page for rename() seems=
 to
>> indicate that overwriting an existing file also introduces a window where
>> the old and new path are hard links to the same file.  This isn't a prob=
lem
>> for the WAL files because we should never be overwriting an existing one,
>> but I wonder if it's a problem for other code paths.  My guess is that m=
any
>> code paths that overwrite an existing file are first writing changes to a
>> temporary file before atomically replacing the original.  Those paths are
>> likely okay, too, as you can usually just discard any existing temporary
>> files.
>=20
> I wonder if this is really true. I thought rename() was supposed to be at=
omic.

Not always.  For example, some old versions of MacOS have a non-atomic
implementation of rename(), like prairiedog with 10.4.  Even 10.5 does
not handle atomicity as far as I call.  In short, it looks like a bad
idea to me to rely on this idea at all.  Some FSes have their own way
of handling things, as well, but I am not much into this world.

Saying that, it would be nice to see durable_rename_excl() gone as it
has created quite a bit of pain for us in the past years.
--
Michael

--8hotg91fg1rYekFA
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmJdF9MACgkQnvQgOdby
QH2EyBAAjqC/9KkVf8qK3L4HlnnWWkSwq1Nv+vzFB80Yv+/vCHDZz4riCDkJO4KW
Rco60wG2DTt4Eddu2w0OZdCyrEKTXvzzZsDqt5ltC17WJVyxkVNVYj45b649DTEb
52dnBcsp/SSatAKxxEfRE/B1Qln6WcO17vLYQBjutV19PGqwqxFQLhWhrZcV77Pf
Uh558YCPXArY72ztukELlTr58PgJAHDvdejdJ3ol4EXEkEK6Mw86Jhg2jd2g3fMm
5Sk69wxwxaa4Kq9V0EOE2EPwZDt30VWaNNJsQdwYKNMpg5jB5lJQUmj+MfzVRVbF
u4DfjjLIrVQRdVGO9wCC1iPz48nQWlNHiexmetCDHyTx3NvU0jM2xzr7uf+GkQJc
42mmGulB+T2oZN5Do/ZI8wyymXAtDqSDqNSXxFYmImT4XwC8WTVGeiYgvH+x7nS7
yDxwHf5iFhohEEqLeKStXmBeR0wx8SsZm3z9Qv1JgMBP4cTlL1qGa5v5IXnov0i4
/IZJWwsnHEO1EZWjGO4w7pkFpTiAJOXeyvM8xZ/Py2QRlT7ekDRevsjVYAOj/Rg0
Dljcfa4OmKXLD9r02+ucKllpppwZRrMNlyHMPsebBmscpirqGGA7tm6bC/UZV+h6
+7+fkyaBYc1PYjsPKdi+6vaDIYfzV1xvUynp8bysFbOUU8vCm1w=
=UIP5
-----END PGP SIGNATURE-----

--8hotg91fg1rYekFA--