Re: pg_amcheck contrib application

> On Mar 16, 2021, at 9:30 AM, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> wrote:
>
>
>
>> On Mar 16, 2021, at 9:07 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> writes:
>>> I think autovacuum simply triggers the bug, and is not the cause of the bug. If I turn autovacuum off and instead do an ANALYZE in each test database rather than performing the corruptions, I get reports about problems in pg_statistic. This is on my mac laptop. This rules out the theory that autovacuum is propogating corruptions into pg_statistic, and also the theory that it is architecture dependent.
>>
>> I wonder whether amcheck is confused by the declaration of those columns
>> as "anyarray".
>
> It uses attlen and attalign for the attribute, so that idea does make sense. It gets that via TupleDescAttr(RelationGetDescr(rel), attnum).

Yeah, that looks related:

regression=# select attname, attlen, attnum, attalign from pg_attribute where attrelid = 2619 and attname like 'stavalue%';
attname | attlen | attnum | attalign
------------+--------+--------+----------
stavalues1 | -1 | 27 | d
stavalues2 | -1 | 28 | d
stavalues3 | -1 | 29 | d
stavalues4 | -1 | 30 | d
stavalues5 | -1 | 31 | d
(5 rows)

It shows them all has having attalign = 'd', but for some array types the alignment will be 'i', not 'd'. So it's lying a bit about the contents. But I'm now confused why this caused problems on the two hosts where integer and double have the same alignment? It seems like that would be the one place where the bug would not happen, not the one place where it does.

I'm attaching a test that reliably reproduces this for me: