Horton

Re: BUG #17064: Parallel VACUUM operations cause the error "global/pg_filenode.map contains incorrect checksum"

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
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>
Date: 2021-06-22T14:11:06Z
Lists: pgsql-bugs 
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

Commits

  1. Another fix to relmapper race condition.

  2. Prevent race condition while reading relmapper file.