Re: pg_verify_checksums and -fno-strict-aliasing
От | Magnus Hagander |
---|---|
Тема | Re: pg_verify_checksums and -fno-strict-aliasing |
Дата | |
Msg-id | CABUevEy8wwcyfeJyCst0ZANnKCi4W9wM_HmyOrH7ERY9QyWLQg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_verify_checksums and -fno-strict-aliasing (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: pg_verify_checksums and -fno-strict-aliasing
|
Список | pgsql-hackers |
On Thu, Aug 30, 2018 at 10:02 PM, Michael Paquier <michael@paquier.xyz> wrote:
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 ;)
Haha, nice timing :)
I wonder if your tests that pg_control has picked things up belong more in the tests of initdb itself?
Do you think there is value in testing against a non-checksum cluster? I guess there's some point to it. I think testing actual corruption (like my version of the tests) is more valuable, but perhaps we should just do both?
В списке pgsql-hackers по дате отправления: