Re: pg_amcheck contrib application

> On Apr 14, 2021, at 10:17 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Mon, Apr 12, 2021 at 11:06 PM Mark Dilger
> <mark(dot)dilger(at)enterprisedb(dot)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 multiple missing chunks and multiple extraneous chunks, as it makes it easier for the user to reconcile the missing chunks against 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

Changed.

> (Notice that I also inserted "has" so that the sentence a verb. Or we
> could "contains.")

I have added the verb "has" rather than "contains" because "has" is more consistent with the phrasing of other similar corruption reports.