Horton

Re: pg_verify_checksums and -fno-strict-aliasing

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Banck <michael.banck@credativ.de>, Magnus Hagander <magnus@hagander.net>, Fabien COELHO <coelho@cri.ensmp.fr>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-08-30T23:12:14Z
Lists: pgsql-hackers 
On 2018-08-30 19:02:15 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > It certainly should be warned about.  Practically I don't think it's a
> > problem, because we pretty much always operate on a copy of the page
> > when writing out, as otherwise concurrently set hint bits would be
> > troublesome.
> 
> The write end of things is not a problem IMO, since presumably the caller
> would be about to overwrite the checksum field anyway.  The issue is for
> reading and/or verifying, where it's much less obvious that clobbering
> the page image is safe.

With "reading" you mean putting the page into the buffercache? If so,
that should be ok, the page isn't yet accessible (BM_VALID isn't set).

I don't think it's possible to do verification from the page in s_b,
because we don't keep the checksum current, so there should never be
calls to do so.

But we probably should still add a comment making clear that the
function modifies the buffer temporarily.

Greetings,

Andres Freund

Commits

  1. Avoid using potentially-under-aligned page buffers.

  2. Code review for pg_verify_checksums.c.

  3. Make checksum_impl.h safe to compile with -fstrict-aliasing.