> On Apr 8, 2021, at 3:11 PM, Robert Haas <robertmh...@gmail.com> wrote:
>
> 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.
#2 is if chunk_seq goes up but skips numbers. #3 is if chunk_seq ever goes
down, meaning the index scan did something unexpected.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
