Re: pg_upgrade automatic testing
От | Tom Lane |
---|---|
Тема | Re: pg_upgrade automatic testing |
Дата | |
Msg-id | 22841.1314990268@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade automatic testing (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: pg_upgrade automatic testing
Re: pg_upgrade automatic testing |
Список | 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
В списке pgsql-hackers по дате отправления: