Re: [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument" - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"
Date
Msg-id 19485.1475344891@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> On 09/30/2016 12:24 PM, Tom Lane wrote:
>> Seems to be some additional prep work needed somewhere ...
>> No upgrade_install_root at /home/bfarm/bf-scripts/build-farm-4.17/PGBuild/Modules/TestUpgradeXversion.pm line 51.

> Oh sorry, you also need an entry for that in the config file. Mine has:
>     upgrade_install_root => '/home/bf/bfr/root/upgrade',

Yesterday's runs of prairiedog had this turned on.  I'm not sure how
to interpret the output (because there isn't any, ahem), but it does
not appear that the test detected anything wrong.

I was able to demonstrate the problem, and that my patch of yesterday
fixed it, by building a table in 9.5 that was all-visible, deleting a few
widely scattered tuples, and then pg_upgrading.  It wasn't that easy to
exhibit a query failure, though --- my first attempt failed because I'd
done an index-only scan in 9.5 before upgrading, and that had the side
effect of marking the index tuples dead, making the same query in HEAD
produce correct answers despite having invalid vismap state.  If we wanted
a regression test, it seems like we would have to build a custom test
specifically designed to detect this type of problem, and I'm not sure
it's worth it.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Show hash / bitmap sizes in EXPLAIN ANALYZE?
Next
From: Tomas Vondra
Date:
Subject: Re: Macro customizable hashtable / bitmapscan & aggregation perf