From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
cc: 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"
In-reply-to: 
 <CA+hUKGJ98=MOjDCnMAC5gSpkzrrey=O+aEQJ1OY03C=cVtiwkA@mail.gmail.com>
References: <17064-bb0d7904ef72add3@postgresql.org>
 <ac119d1e-05d1-f050-b92a-0a524d68b848@iki.fi>
 <CA+hUKGJ98=MOjDCnMAC5gSpkzrrey=O+aEQJ1OY03C=cVtiwkA@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@gmail.com>
	message dated "Wed, 23 Jun 2021 01:00:31 +1200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1715250.1624371066.1@sss.pgh.pa.us>
Date: Tue, 22 Jun 2021 10:11:06 -0400
Message-ID: <1715251.1624371066@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1715251.1624371066%40sss.pgh.pa.us>
Precedence: bulk

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?

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?

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.

			regards, tom lane