On Thu, Apr 8, 2021 at 5:21 PM Mark Dilger <mark.dil...@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 we got > 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 than expected by M bytes, and that the total size was smaller than we > expected by N bytes. The third of those is somewhat misleading, since the > final chunk was presumably the right size; we just weren't expecting to hit a > partial chunk quite 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
