> On Apr 14, 2021, at 10:17 AM, Robert Haas <robertmh...@gmail.com> wrote: > > 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
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.
v21-0001-amcheck-adding-toast-pointer-corruption-checks.patch
Description: Binary data
— Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
