Re: pg_upgrade automatic testing
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <bruce@momjian.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-09-02T19:04:28Z
Lists: pgsql-hackers
Bruce Momjian <bruce@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