Horton

Re: pg_verify_checksums and -fno-strict-aliasing

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Magnus Hagander <magnus@hagander.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Fabien COELHO <coelho@cri.ensmp.fr>, Michael Banck <michael.banck@credativ.de>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-08-30T20:02:58Z
Lists: pgsql-hackers

Attachments

On Thu, Aug 30, 2018 at 09:35:33PM +0200, Magnus Hagander wrote:
> Should we make it a separate test in pg_verify_checksums, or should we
> piggyback on the pg_basebackup tests (which AFAICT is the only ones that
> create a cluster with checksums enabled at all, and thus is the only
> codepath that actually uses the backend checksum code at all, which I think
> is an even worse thing to have no tests of)

This should be a separate suite.  And FWIW, we only use pg_regress to
make sure that an already-initialized data folder has the correct,
secure authentication set.  So creating a node with checksums enabled is
just that:
$node->init(extra => ['--data-checksums']);

[... 20 minutes later ...]
Attached is a basic test suite ;)
--
Michael

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.