Re: BUG #15896: pg_upgrade from 10-or-earlier: TRAP: FailedAssertion(»!(metad->btm_version >= 3)«
От | Peter Geoghegan |
---|---|
Тема | Re: BUG #15896: pg_upgrade from 10-or-earlier: TRAP: FailedAssertion(»!(metad->btm_version >= 3)« |
Дата | |
Msg-id | CAH2-WzkUd0aqrdwjK=pOBHvLd=PBKgu8Dn+tP5+=CnHzadjoEQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #15896: pg_upgrade from 10-or-earlier: TRAP: FailedAssertion(»!(metad->btm_version >= 3)« (Christoph Berg <myon@debian.org>) |
Ответы |
Re: BUG #15896: pg_upgrade from 10-or-earlier: TRAP: FailedAssertion(»!(metad->btm_version >= 3)«
|
Список | pgsql-bugs |
On Tue, Jul 16, 2019 at 1:13 AM Christoph Berg <myon@debian.org> wrote: > I applied the patch to 12/HEAD and the Debian testsuite now passes the > 10->12 upgrade test. Thanks for testing! 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? AFAICT the only purpose that _bt_cachemetadata() serves that isn't better handled by updating the assertions that were failing back in April of 2018 (and still sometimes fail) is initializing the new-to-v3 fields defensively (initializing btm_oldest_btpo_xact and btm_last_cleanup_num_heap_tuples are set to their default values). Even that seems unnecessary, since every piece of code knows that it isn't sensible to read those values. Including contrib/pageinspect, which was actually taught this by commit 0a64b45152b itself. I'm a bit nervous about pushing a commit that will almost be a straight revert of 0a64b45152b without first getting confirmation that _bt_cachemetadata() is actually totally unnecessary. -- Peter Geoghegan
В списке pgsql-bugs по дате отправления: