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

On Thu, Jul 18, 2019 at 1:57 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> I wonder what the consequences are in a system that doesn't have
> assertions enabled. Do we just end up with an "upgraded" cached
> metapage, and no further ill effects? That seems pretty benign ...

AFAICT, it's benign. The new fields added to the metapage by commit
857f9c36cda were put there because that happened to be convenient.
They were only really something that VACUUM is expected to care about.
The usual concerns about having a stale meta page don't apply to those
fields.

The design of commit 0a64b45152b seems to have been "let's just
pretend that it's a v3 page in the cached version, not a v2 page,
since code that might used a cached version won't care about the
difference, and code that does care about the difference definitely
won't use the cache". This was made much more complicated by the fact
that 0a64b45152b didn't really seem to admit that it was doing this --
it's very weird that the cached version could be *ahead of* the
authoritative version.

It's now possible that the cached version number will become stale on
v11, but that should be harmless for the same reason as it was
harmless when it happened in the opposite direction. Besides, there
are well established ways in which a cached nbtree metapage is allowed
to become stale -- comments above _bt_getrootheight() have always said
that that's okay.

The situation here was confusing enough that it seemed worth
backpatching a fix to v11, even though I believe that nobody using v11
will have see any misbehavior related to commit 0a64b45152b.

> I hope we don't end up with an expected v4 metapage or something crazy
> like that? (I suppose we would have noticed.)

I think that we'd have heard about it by now.

--
Peter Geoghegan