Re: pg_upgrade automatic testing
От | Bruce Momjian |
---|---|
Тема | Re: pg_upgrade automatic testing |
Дата | |
Msg-id | 201109021753.p82HruK26046@momjian.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade automatic testing (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
Peter Eisentraut wrote: > On tor, 2011-09-01 at 18:55 -0400, Bruce Momjian wrote: > > Tom Lane wrote: > > > 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 > > > > Reminder --- you can't use pg_upgrade to go from the same catalog > > version to the same catalog version because the catalog version is > > embedded in the tablespace directory name. > > Well, it does work, but only because the regression tests don't keep a > tablespace around at the end. Would pg_upgrade complain otherwise? The restriction is only for old clusters that contain tablespaces, and you get this error message during the check phase: Cannot migrate to/from the same system catalog version whenusing tablespaces. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: