Re: Online verification of checksums

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Michael Banck <michael(dot)banck(at)credativ(dot)de>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Online verification of checksums
Date: 2019-02-28 13:29:45
Message-ID: alpine.DEB.2.21.1902171410130.3339@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hallo Mickael,

> So I have now changed behaviour so that short writes count as skipped
> files and pg_verify_checksums no longer bails out on them. When this
> occors a warning is written to stderr and their overall count is also
> reported at the end. However, unless there are other blocks with bad
> checksums, the exit status is kept at zero.

This seems fair when online, however I'm wondering whether it is when
offline. I'd say that the whole retry logic should be skipped in this
case? i.e. "if (block_retry || !online) { error message and continue }"
on both short read & checksum failure retries.

> New patch attached.

Patch applies cleanly, compiles, global & local make check ok.

I'm wondering whether it should exit(1) on "lseek" failures. Would it make
sense to skip the file and report it as such? Should it be counted as a

WRT the final status, ISTM that slippedblocks & files could warrant an
error when offline, although they might be ok when online?


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-02-28 13:59:58 Re: Why don't we have a small reserved OID range for patch revisions?
Previous Message David Rowley 2019-02-28 13:20:26 Re: pgbench MAX_ARGS