On Fri, Apr 30, 2021 at 3:41 PM Mark Dilger
<mark.dil...@enterprisedb.com> wrote:
> I think that's committable.
>
> The only nitpick might be
>
> - psprintf("toast value %u was expected to end
> at chunk %d, but ended at chunk %d",
> + psprintf("toast value %u index scan ended
> early while expecting chunk %d of %d",
>
> When reporting to users about positions within a zero-based indexing scheme,
> what does "while expecting chunk 3 of 4" mean? Is it talking about the last
> chunk from the set [0..3] which has cardinality 4, or does it mean the
> next-to-last chunk from [0..4] which ends with chunk 4, or what? The prior
> language isn't any more clear than what you have here, so I have no objection
> to committing this, but the prior language was probably as goofy as it was
> because it was trying to deal with this issue.
Hmm, I think that might need adjustment, actually. What I was trying
to do is compensate for the fact that what we now have is the next
chunk_seq value we expect, not the last one we saw, nor the total
number of chunks we've seen regardless of what chunk_seq they had. But
I thought it would be too confusing to just give the chunk number we
were expecting and not say anything about how many chunks we thought
there would be in total. So maybe what I should do is change it to
something like this:
toast value %u was expected to end at chunk %d, but ended while
expecting chunk %d
i.e. same as the currently-committed code, except for changing "ended
at" to "ended while expecting."
--
Robert Haas
EDB: http://www.enterprisedb.com
