| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| 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-11 08:15:53 |
| Message-ID: | 20190711081553.GI4500@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Thu, Jul 11, 2019 at 12:18:46AM -0700, Peter Geoghegan wrote:
> On Fri, Jul 5, 2019 at 3:14 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>> _bt_getrootheight() is mostly just something that exists for the
>> planner, so it has no business calling _bt_cachemetadata(), which will
>> "upgrade" the cached metadata image from version 2 to version 3 if it
>> happens to be on version 2. How can it be okay to upgrade the cached
>> version without also upgrading the on-disk/shared_buffers version?
>> This bug was hiding in plain sight.
>
> CC'ing Alexander, who was also involved in commit 0a64b45152b...
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. 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.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | 甄明洋 | 2019-07-11 10:48:11 | The result of the pattern matching is incorrect when the pattern string is bpchar type |
| Previous Message | Peter Geoghegan | 2019-07-11 07:18:46 | Re: BUG #15896: pg_upgrade from 10-or-earlier: TRAP: FailedAssertion(»!(metad->btm_version >= 3)« |