BUG #18135: Incorrect memory access occurs when attaching a partition with an index

The following bug has been logged on the website:

Bug reference: 18135
Logged by: Alexander Lakhin
Email address: exclusion(at)gmail(dot)com
PostgreSQL version: 16.0
Operating system: Ubuntu 22.04
Description:

When the following query:
CREATE TABLE t(a int) PARTITION BY RANGE (a);
CREATE INDEX ON t((a + 1));

CREATE TABLE tp(a int not null) PARTITION BY RANGE (a);
CREATE INDEX ON tp((a));

ALTER TABLE t ATTACH PARTITION tp FOR VALUES FROM (0) TO (1);

executed under Valgrind, it leads to an incorrect memory access:
==00:00:00:03.947 396156== Invalid read of size 2
==00:00:00:03.947 396156== at 0x2E323D: CompareIndexInfo (index.c:2572)
==00:00:00:03.947 396156== by 0x3D009B: AttachPartitionEnsureIndexes
(tablecmds.c:18797)
==00:00:00:03.947 396156== by 0x3D8B4F: ATExecAttachPartition
(tablecmds.c:18578)
==00:00:00:03.947 396156== by 0x3D9A88: ATExecCmd (tablecmds.c:5379)
==00:00:00:03.947 396156== by 0x3D9BC7: ATRewriteCatalogs
(tablecmds.c:5063)
==00:00:00:03.947 396156== by 0x3D9E29: ATController (tablecmds.c:4638)
==00:00:00:03.947 396156== by 0x3D9EB3: AlterTable (tablecmds.c:4293)
==00:00:00:03.947 396156== by 0x5FAC30: ProcessUtilitySlow
(utility.c:1329)
==00:00:00:03.947 396156== by 0x5FA6C4: standard_ProcessUtility
(utility.c:1078)
==00:00:00:03.947 396156== by 0x5FA789: ProcessUtility (utility.c:530)
==00:00:00:03.947 396156== by 0x5F7B46: PortalRunUtility
(pquery.c:1158)
==00:00:00:03.947 396156== by 0x5F7E40: PortalRunMulti (pquery.c:1315)
==00:00:00:03.947 396156== Address 0x10736bbe is 2,446 bytes inside a
recently re-allocated block of size 8,192 alloc'd
==00:00:00:03.947 396156== at 0x4848899: malloc
(vg_replace_malloc.c:381)
==00:00:00:03.947 396156== by 0x768F55: AllocSetContextCreateInternal
(aset.c:444)
==00:00:00:03.947 396156== by 0x7512FF: hash_create (dynahash.c:385)
...

The function CompareIndexInfo() contains the code:
/* ignore expressions at this stage */
if ((info1->ii_IndexAttrNumbers[i] != InvalidAttrNumber) &&
(attmap->attnums[info2->ii_IndexAttrNumbers[i] - 1] !=
info1->ii_IndexAttrNumbers[i]))
return false;

where info1->ii_IndexAttrNumbers[i] is checked for InvalidAttrNumber
(i. e. it's not an expression), but info2->ii_IndexAttrNumbers[i] is not.
In addition, there is a check whether both indexes are (are not)
expression
indexes, but it's placed below...