Re: pg_amcheck contrib application

Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> writes:
> On Mar 15, 2021, at 10:04 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

> 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. The fact that we're seeing
this on just those two animals suggests strongly to me that it's
architecture-correlated, instead.

regards, tom lane