Re: pg_amcheck contrib application

Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> writes:
> On Mar 16, 2021, at 10:48 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> (Too bad the message doesn't report the
>> TOAST OID it probed for, so we can see if that's sane or not.)

> I've added that and now get the toast pointer's va_valueid in the message:

> heap table "postgres"."pg_catalog"."pg_statistic", block 4, offset 2, attribute 29:
> toasted value id 13227 for attribute 29 missing from toast table
> heap table "postgres"."pg_catalog"."pg_statistic", block 4, offset 5, attribute 27:
> toasted value id 13228 for attribute 27 missing from toast table

That's awfully interesting, because OIDs less than 16384 should
only be generated during initdb. So what we seem to be looking at
here is pg_statistic entries that were made during the ANALYZE
done by initdb (cf. vacuum_db()), and then were deleted during
a later auto-analyze (in the buildfarm) or deliberate analyze
(in your reproducer). But if they're deleted, why is amcheck
looking for them?

I'm circling back around to the idea that amcheck is trying to
validate TOAST references that are already dead, and it's getting
burnt because something-or-other has already removed the toast
rows, though not the referencing datums. That's legal behavior
once the rows are marked dead. Upthread it was claimed that
amcheck isn't doing that, but this looks like a smoking gun to me.

regards, tom lane