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

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Christoph Berg <myon(at)debian(dot)org>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
Subject: Re: BUG #15896: pg_upgrade from 10-or-earlier: TRAP: FailedAssertion(»!(metad->btm_version >= 3)«
Date: 2019-07-12 03:31:37
Message-ID: CAH2-Wz=qGWcu-z3r=e4mhFtjKqUuHYPqfVmcWSRH-1F4ycvG6Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Jul 11, 2019 at 1:16 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> So the problem has been introduced in v11 per this commit, still we
> only see the issue since v12 because your code relied on a wrong
> assumption.

We see the issue on v12 because my code added an assertion that caught
the issue. The behavior on v12 is otherwise substantively the same as
on v11. Even if it was true that my commits made nbtree rely on the
same "wrong assumption" more often than on v11, why would it matter?
The bug is still a v11 bug.

> Per what I am reading, it seems to me that we should fix
> v11, but that's a live problem for v12 because of the page format
> upgrade so we need to track it as an open item.

The highest priority ought to be fixing the problem in the stable v11
branch. That said, there is hardly any difference between v11 and v12.
It isn't possible to upgrade a B-Tree index from v2/v3 to v4 (the
latest version) on-the-fly. But if in your judgement it makes sense to
add a v12 open item, I have no objection.

--
Peter Geoghegan

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message David Rowley 2019-07-12 03:54:01 Re: PG11 - Multiple Key Range Partition
Previous Message Michael Paquier 2019-07-12 01:25:03 Re: BUG #15888: Bogus "idle in transaction" state for logical decoding client after creating a slot