On Mon, Mar 15, 2021 at 02:57:20PM -0400, Tom Lane wrote: > Mark Dilger <mark.dil...@enterprisedb.com> writes: > > On Mar 15, 2021, at 10:04 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> These animals have somewhat weird alignment properties: MAXALIGN is 8 > >> but ALIGNOF_DOUBLE is only 4. I speculate that that is affecting their > >> choices about whether an out-of-line TOAST value is needed, breaking > >> this test case.
That machine also has awful performance for filesystem metadata operations, like open(O_CREAT). Its CPU and read()/write() performance are normal. > > The logic in verify_heapam only looks for a value in the toast table if > > the tuple it gets from the main table (in this case, from pg_statistic) > > has an attribute that claims to be toasted. The error message we're > > seeing that you quoted above simply means that no entry exists in the > > toast table. > > Yeah, that could be phrased better. Do we have a strong enough lock on > the table under examination to be sure that autovacuum couldn't remove > a dead toast entry before we reach it? But this would only be an > issue if we are trying to check validity of toasted fields within > known-dead tuples, which I would argue we shouldn't, since lock or > no lock there's no guarantee the toast entry is still there. > > Not sure that I believe the theory that this is from bad luck of > concurrent autovacuum timing, though. With autovacuum_naptime=1s, on hornet, the failure reproduced twice in twelve runs. With v6-0001-Turning-off-autovacuum-during-corruption-tests.patch applied, 196 runs all succeeded. > The fact that we're seeing > this on just those two animals suggests strongly to me that it's > architecture-correlated, instead. That is possible.
