Bruce Momjian <br...@momjian.us> writes: > Andrew Dunstan wrote: >> In any case, it would be good to get rid of the limitation if possible. >> Then we could look at creating an automated test that we could use in >> the buildfarm.
> Well, the idea of using the catalog version was that it is something we > expect would change during any change in the system catalogs or internal > data format that would require the use of pg_upgrade. I am unclear what > other fixed value we could use for this. 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. The other reasonable use-case for pg_upgrade is migrating a development or beta-test installation across a catversion bump, but again the tablespace directory name is not a restriction. Perhaps we could have a test that involves checking out the commit-just-before-the-last-catversion-change and seeing if we can migrate from that. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers