Re: pg_upgrade automatic testing
От | Tom Lane |
---|---|
Тема | Re: pg_upgrade automatic testing |
Дата | |
Msg-id | 26374.1314735936@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade automatic testing (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: pg_upgrade automatic testing
Re: pg_upgrade automatic testing Re: pg_upgrade automatic testing |
Список | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.net> writes: > +# contrib/pg_upgrade/test.sh > +# > +# Test driver for pg_upgrade. Initializes a new database cluster, > +# runs the regression tests (to put in some data), runs pg_dumpall, > +# runs pg_upgrade, runs pg_dumpall again, compares the dumps. Hm .. my experience is that that doesn't work at all, because the regression tests set up assorted C functions whose implementations are in pg_regress.so, and it creates them with absolute path references to pg_regress.so. When you try to load that into another installation that's a different version of PG, it quite properly fails. So I think that as given, this script is only useful for testing pg_upgrade of $currentversion to $currentversion. Which is surely better than no test at all, but it would not for example have caught the 8.3 incompatibility that was just reported. How can we improve things here? I've toyed with the idea of installing pg_regress.so so that we can refer to it relative to $libdir, but that might be a bit invasive, especially if we were to try to back-patch it as far as 8.3. regards, tom lane
В списке pgsql-hackers по дате отправления: