On Mon, Apr 12, 2021 at 11:06 PM Mark Dilger
<mark.dilger@enterprisedb.com> wrote:
> It now reports:
>
> # heap table "postgres"."public"."test", block 0, offset 18, attribute 2:
> # toast value 16461 missing chunk 3 with expected size 1996
> # heap table "postgres"."public"."test", block 0, offset 18, attribute 2:
> # toast value 16461 was expected to end at chunk 6 with total size 10000, but ended at chunk 5 with total size
8004
>
> It sounds like you weren't expecting the second of these reports. I think it is valuable, especially when there are
multiplemissing chunks and multiple extraneous chunks, as it makes it easier for the user to reconcile the missing
chunksagainst the extraneous chunks.
I wasn't, but I'm not overwhelmingly opposed to it, either. I do think
I would be in favor of splitting this kind of thing up into two
messages:
# toast value 16459 unexpected chunks 1000 through 1004 each with
size 1996 followed by chunk 1005 with size 20
We'll have fewer message variants and I don't think any real
regression in usability if we say:
# toast value 16459 has unexpected chunks 1000 through 1004 each
with size 1996
# toast value 16459 has unexpected chunk 1005 with size 20
(Notice that I also inserted "has" so that the sentence a verb. Or we
could "contains.")
I committed 0001.
--
Robert Haas
EDB: http://www.enterprisedb.com
