> On Apr 14, 2021, at 10:17 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> 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
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
corruptionreports.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
