Re: pg_amcheck contrib application

On Thu, Apr 8, 2021 at 5:21 PM Mark Dilger <mark.dilger@enterprisedb.com> wrote:
> All this leads me to believe that we should report the following:
>
> 1) If the total number of chunks retrieved differs from the expected number, report how many we expected vs. how many
wegot 
> 2) If the chunk_seq numbers are discontiguous, report each discontiguity.
> 3) If the index scan returned chunks out of chunk_seq order, report that
> 4) If any chunk is not the expected size, report that
>
> So, for your example of chunk 1 missing from chunks [0..17], we'd report that we got one fewer chunks than we
expected,that the second chunk seen was discontiguous from the first chunk seen, that the final chunk seen was smaller
thanexpected by M bytes, and that the total size was smaller than we expected by N bytes.  The third of those is
somewhatmisleading, since the final chunk was presumably the right size; we just weren't expecting to hit a partial
chunkquite yet.  But I don't see how to make that better in the general case. 

Hmm, that might be OK. It seems like it's going to be a bit verbose in
simple cases like 1 missing chunk, but on the plus side, it avoids a
mountain of output if the raw size has been overwritten with a
gigantic bogus value. But, how is #2 different from #3? Those sound
like the same thing to me.

--
Robert Haas
EDB: http://www.enterprisedb.com