On 2018-04-06 17:59:28 -0700, Andres Freund wrote:
> + /*
> + * Create a database list. We don't need to concern ourselves with
> + * rebuilding this list during runtime since any database created after
> + * this process started will be running with checksums turned on from the
> + * start.
> + */
>
> Why is this true? What if somebody runs CREATE DATABASE while the
> launcher / worker are processing a different database? It'll copy the
> template database on the filesystem level, and it very well might not
> yet have checksums set? Afaict the second time we go through this list
> that's not cought.
*caught
It's indeed trivial to reproduce this, just slowing down a checksum run
and copying the database yields:
./pg_verify_checksums -D /srv/dev/pgdev-dev
pg_verify_checksums: checksum verification failed in file "/srv/dev/pgdev-dev/base/16385/2703", block 0: calculated
checksum45A7 but expected 0
pg_verify_checksums: checksum verification failed in file "/srv/dev/pgdev-dev/base/16385/2703", block 1: calculated
checksum8C7D but expected 0
further complaints:
The new isolation test cannot be re-run on an existing cluster. That's
because the first test expects isolationtests to be disabled. As even
remarked upon:
# The checksum_enable suite will enable checksums for the cluster so should
# not run before anything expecting the cluster to have checksums turned off
How's that ok? You can leave database wide objects around, but the
cluster-wide stuff needs to be cleaned up.
The tests don't actually make sure that no checksum launcher / apply is
running anymore. They just assume that it's gone once the GUC shows
checksums have been set. If you wanted to make the tests stable, you'd
need to wait for that to show true *and* then check that no workers are
around anymore.
If it's not obvious: This isn't ready, should be reverted, cleaned up,
and re-submitted for v12.
Greetings,
Andres Freund