Re: BUG #15896: pg_upgrade from 10-or-earlier: TRAP: FailedAssertion(»!(metad->btm_version >= 3)«

On Wed, Jul 17, 2019 at 4:10 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> I am not quite sure if I should push ahead with this, simply because I
> don't know what the point of commit 0a64b45152b really was (Alexandar?
> Teodor?). Why not just make the assertions a bit more less strict in
> one or two places? Is the _bt_cachemetadata() function really
> necessary? Can we remove it now?

Attached revision of the patch shows what I have in mind -- this is
almost a straight revert of 0a64b45152b. This is really no different
than the first version, though it couldn't hurt to test it once more
if you have time, Christoph.

I wonder why commit 0a64b45152b didn't look like this in the first
place. My approach is the obvious way to fix the problem that
0a64b45152b was designed to fix. Am I missing something?

Prior to Postgres v11, we never supported upgrades -- the nbtree
version was 2 for many many years (since before we even had pg_upgrade
to worry about). Obviously that meant that assertions that looked like
"Assert(metad->btm_version == BTREE_VERSION)" had to be updated by
commit 857f9c36cda (this was a big feature commit that commit
0a64b45152b tried to fix-up). It looks like commit 857f9c36cda simply
missed a few assertions in the upgrade path, including
_bt_getrootheight(). So, again, I don't know why commit 0a64b45152b
had to go any further than updating 2 or 3 assertions that were
overlooked in commit 857f9c36cda.

--
Peter Geoghegan