On Mon, Apr 12, 2021 at 11:06 PM Mark Dilger <mark.dil...@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 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 (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
