Andrew Dunstan wrote: > > > On 09/02/2011 01:55 PM, Bruce Momjian wrote: > > Andrew Dunstan wrote: > >> > >> On 09/02/2011 10:36 AM, Peter Eisentraut wrote: > >>> On tor, 2011-09-01 at 18:55 -0400, Bruce Momjian wrote: > >>>> Tom Lane wrote: > >>>>> Peter Eisentraut<pete...@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? > >>> > >> 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. > > Why not use a prefix like 'd_' and 's_' so they can't be identical?
What would 'd' and 's' mean? Destination and Source? That doesn't help us because a destination today might be a source tomorrow and we don't rename these tablespace directory names. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
