Re: pg_verify_checksums -d option (was: Re: pg_verify_checksums -r option)

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
Cc: Michael Banck <michael(dot)banck(at)credativ(dot)de>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_verify_checksums -d option (was: Re: pg_verify_checksums -r option)
Date: 2018-09-03 17:14:41
Message-ID: alpine.DEB.2.21.1809031717240.5293@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Yugo-san,

> I attached the rebased patch.

Patch applies cleanly, compiles, "make check" is okay, although there are
no specific test for the feature. Indeed, after investigation there is not
a SINGLE test for the command:-(

I think that some minimal tap-testing should be done. It seems that
pg_basebackup tap test is the only one which enables checksums. Maybe a
pg_verify_checksum could be added to the "010_pg_basebackup.pl" script.

Anyway I tested that it works by hex-editing a file to trigger a fail.

Function "atoi" is quite lazy, it accepts "-d 1zzz" as "1". Maybe parsing
could be stricter.

When the command is started with both "-d 1 -g", it succeeds by checking
nothing, which is quite misleading. Probably it should complain that these
options are mutually exclusive, or it should check both under -g AND -d 1?

The oid of a database is not obvious... You have to query "SELECT oid, *",
it is not given by \l or \l+ or "psql -l".

About the documentation:

"Only validate checksums in the relations in the database with specified
OID."... I think that indexes and other possibly toasted values are also
checked. I'd suggest "Only validate checksums of objects in the database
specified by its OID".

"--globel-only" -> "--global-only".

ISTM that --help should show options in alphabetical order, however -v is
out of order.

--
Fabien.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-09-03 17:30:33 Re: Caching query plan costs
Previous Message Bruce Momjian 2018-09-03 16:01:21 Caching query plan costs