Have you tried to reindex the table? Toast internally forces an index scan, so missing index tuples or an otherwise corrupted toast index would have the same symptoms as toast chunks actually missing.
On Sun, Mar 15, 2020 at 12:58:53PM -0700, Adrian Klaver wrote:
> > > We then tried to DELETE the offending row > > > > > > delete from blobs.doc_obj where pk = 82224; > > > > > > but that, again, shows the "unexpected chunk" problem. > > > > According to > > > > http://www.databasesoup.com/2013/10/de-corrupting-toast-tables.html > > > > an UPDATE of the row is recommended -- should that work > > better than a DELETE ? > > > > I can't find documentation pointing to a fundamental > > implementation difference that suggests so. > > https://www.postgresql.org/docs/12/storage-toast.html#STORAGE-TOAST-ONDISK > > "During an UPDATE operation, values of unchanged fields are normally > preserved as-is; so an UPDATE of a row with out-of-line values incurs no > TOAST costs if none of the out-of-line values change."
However, where is the fault in my thinking ?
-> An UPDATE actually *would* change the TOASTed BYTEA field (which is corrupt).
I had hoped that the DELETE would NOT have to touch the TOAST table at all (and thereby not check the chunks) as "all it needs to do" is mark the row in the *primary* table as not-needed-anymore.
