> On Apr 8, 2021, at 3:11 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> 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
manywe 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
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.
#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
