From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_upgrade automatic testing |
Date: | 2011-09-02 18:15:34 |
Message-ID: | 4E611D46.2040702@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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<peter_e(at)gmx(dot)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?
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2011-09-02 18:25:08 | Re: pg_dump --exclude-table-data |
Previous Message | Magnus Hagander | 2011-09-02 18:14:26 | Re: WAL "low watermark" during base backup |