On fre, 2011-09-02 at 15:04 -0400, Tom Lane wrote: > IMO there's next to no value in testing that scenario anyway, since > nobody would ever use it in the field. What *would* be of value is > testing upgrades from previous release versions. Probably that will > take some work in the buildfarm infrastructure as well as figuring out a > non-problematic test case to use, but that's the direction we need to > head in.
Well, let's take a step back. I originally developed this test runner a few months ago while fixing upgrade issues related to composite types that had been altered. So this is actually useful stuff that would help prevent these sorts of problems in the future, and would help developers fix problems of this sort. But if you think about it, it doesn't really test pg_upgrade, it tests pg_dump. So the test could just as well be moved to src/bin/pg_dump/ and be labeled "pg_dump smoke test" or whatever. (Minor detail: The bug fix above involved the --binary-upgrade flag, so it is somewhat pg_upgrade related.) A real pg_upgrade test suite should naturally upgrade across binary incompatible versions. The real question is how you develop a useful test input. Most pg_upgrade issues are not bugs of omission or regression but unexpected corner cases discovered with databases of nontrivial usage patterns. (The recent one related to upgrade from 8.3 is an exception.) Because the basic premise of pg_upgrade is, dump and restore the schema, move over the files, that's it, and the rest of the code is workarounds for obscure details that are difficult to anticipate let alone test for. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
