Hi Alexander,
On Wed, Sep 16, 2020 at 2:56 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> I was going to tweak this patch in a similar way, but made it in
> advance. Your commit looks good to me, thanks!
I would have left it to you, but we're pretty close to releasing 13,
and I didn't want to risk missing the deadline.
FWIW, the reason that Andrew did not see the same problem when
pg_upgrade'ing from Postgres 11 - Postgres 13 is that the INCLUDE
index feature simplified _bt_insert_parent() for all indexes (not just
indexes with non-key columns). That function used to set the offset
number of the pivot tuple it inserts into the parent to P_HIKEY (even
though that was always unnecessary and unhelpful -- maybe you remember
our discussion about this exact thing in early 2018). The pre-11
behavior of _bt_insert_parent() broke the assumption that each pivot
tuple's contents (after the downlink/block number) must always have
the same value in the matching pivot tuple one level up.
FWIW, Anastasia was right to say that the INCLUDE index feature
prevented such an inconsistency from arising -- it was v11 that
removed the silly set-P_HIKEY thing (not 12 or 13). However, the only
practical way for amcheck to know for sure that the index can never
have been affected by the P_HIKEY thing is to check that the index is
a heapkeyspace index (i.e. an index built by Postgres 12 or 13).
(Maybe this is obvious, but I thought I'd say it just in case, for the
archives.)
Thanks
--
Peter Geoghegan