Date: Wed, 23 Jun 2021 09:33:47 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Thomas Munro <thomas.munro@gmail.com>,
	Heikki Linnakangas <hlinnaka@iki.fi>,
	Alexander Lakhin <exclusion@gmail.com>,
	PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #17064: Parallel VACUUM operations cause the error
 "global/pg_filenode.map contains incorrect checksum"
Message-ID: <YNKBazxEayjtyb1x@paquier.xyz>
References: <17064-bb0d7904ef72add3@postgresql.org>
 <ac119d1e-05d1-f050-b92a-0a524d68b848@iki.fi>
 <CA+hUKGJ98=MOjDCnMAC5gSpkzrrey=O+aEQJ1OY03C=cVtiwkA@mail.gmail.com>
 <1715251.1624371066@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="xtb97sJ/c4s+k8vM"
Content-Disposition: inline
In-Reply-To: <1715251.1624371066@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/YNKBazxEayjtyb1x%40paquier.xyz>
Precedence: bulk


--xtb97sJ/c4s+k8vM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Jun 22, 2021 at 10:11:06AM -0400, Tom Lane wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
>> Your analysis seems right to me.  We have to worry about both things:
>> atomicity of writes on power failure (assumed to be sector-level,
>> hence our 512 byte struct -- all good), and atomicity of concurrent
>> reads and writes (we can't assume anything at all, so r/w locking is
>> the simplest way to get a consistent read).  Shouldn't relmap_redo()
>> also acquire the lock exclusively?

You are implying anything calling write_relmap_file(), right?

> Shouldn't we instead file a kernel bug report?  I seem to recall that
> POSIX guarantees atomicity of these things up to some operation size.
> Or is that just for pipe I/O?

Even if this is recognized as a bug report, it seems to me that we'd
better cope with an extra lock for instances that may run into this
issue anyway in the future, no?  Just to be on the safe side.

> If we can't assume atomicity of relmapper file I/O, I wonder about
> pg_control as well.  But on the whole, what I'm smelling is a moderately
> recently introduced kernel bug.  We've been doing this this way for
> years and heard no previous reports.

True.  PG_CONTROL_MAX_SAFE_SIZE relies on that.  Now, the only things
updating the control file are the startup process and the checkpointer
so that's less prone to conflicts contrary to the reported problem
here, and the code takes a ControlFileLock where necessary.
--
Michael

--xtb97sJ/c4s+k8vM
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmDSgWsACgkQnvQgOdby
QH2BRA//f6fxg5xtWmDBU0Z2Ogs7vBrkSh0OnuHT1nrItZI4fls/xPVZsPjnrdln
2jsEqmJOuAdyYadHb4PPahN4AvjDP/vLlnZyPsSToYBnuf9WIm7VDpXCU3w/Gdlj
2lQTjsZi10wMSSsrusA+ZAxxbgAkJ171hB9GA54PhLEuv4vHKWpecoORpJe6SkGk
V9CC75WjYQto3dy224UYlf7CId9EGI9QGzs6XlZeWVsU5HIFLZj/+lX4RCsKh1wG
w/ZSowFqPGskDndNXAn0oU4vz1M16Vak5isg43/UzWJzg7q+FUs1zrSemKBM4EHJ
OewIOTvkAFCEHj2kp2qdMRtsXWqG7XcX5g/RW6r0gf90cyU/8zYpcWXlNyJuKxjA
9meuJH0usG7odGTJuXlpkVdiW2XMopiaFN5kSZCaQ+hmfwAGEHUDaN7PlcLXmi76
IlAK8zZHDORDKw0MahRr/BtJk+kLMzOWK+ABUQbSHicKfoMIki7q5QLtJNWexk6l
dwR6ODnULSD5R5hkF6V11+SCCvjsgYDoMxmHs0UiEvzbtELmRoDf6tR+lhvbEAvE
WIbIJikPFs4823/3ULE/cuXa842TVqOuWA50XvmC5XFoyvYSrXE6ido1h/60ov3F
rgu3xpcDILnokqDvwAfDXC+Z+4UtK7IkashW7+Nkkxl6JssOQc0=
=2LMr
-----END PGP SIGNATURE-----

--xtb97sJ/c4s+k8vM--