On 3/6/19 6:42 PM, Andres Freund wrote: >
...
>
To me the right way seems to be to IO lock the page via PG after such a failure, and then retry. Which should be relatively easily doable for the basebackup case, but obviously harder for the pg_verify_checksums case.
Actually, what do you mean by "IO lock the page"? Just waiting for the current IO to complete (essentially BM_IO_IN_PROGRESS)? Or essentially acquiring a lock and holding it for the duration of the check?
The former does not really help, because there might be another I/O request initiated right after, interfering with the retry.
The latter might work, assuming the check is fast (which it probably is). I wonder if this might cause issues due to loading possibly corrupted data (with invalid checksums) into shared buffers. But then again, we could just hack a special version of ReadBuffer_common() which would just
(a) check if a page is in shared buffers, and if it is then consider the checksum correct (because in memory it may be stale, and it was read successfully so it was OK at that moment)
(b) if it's not in shared buffers already, try reading it and verify the checksum, and then just evict it right away (not to spoil sb)
Or did you have something else in mind? regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
