From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: ALTER TABLE lock downgrades have broken pg_upgrade |
Date: | 2016-05-03 17:33:49 |
Message-ID: | 5728E0FD.8000501@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 05/03/2016 01:28 PM, Andrew Dunstan wrote:
>
>
> On 05/03/2016 01:21 PM, Stephen Frost wrote:
>> * Alvaro Herrera (alvherre(at)2ndquadrant(dot)com) wrote:
>>> Tom Lane wrote:
>>>
>>>> More generally, though, I wonder how we can have some test coverage
>>>> on such cases going forward. Is the patch below too ugly to commit
>>>> permanently, and if so, what other idea can you suggest?
>>> I suggest a buildfarm animal running a custom buildfarm module that
>>> exercises the pg_upgrade test from every supported version to the
>>> latest
>>> stable and to master -- together with your proposed case that leaves a
>>> toastless table around for pg_upgrade to handle.
>> That would help greatly with pg_dump test coverage as well.. One of the
>> problems of trying to get good LOC coverage of pg_dump is that a *lot*
>> of the code is version-specific...
>>
>
>
> I have an module that does it, although it's not really stable enough.
> But it's a big start.
> See
> <https://github.com/PGBuildFarm/client-code/blob/master/PGBuild/Modules/TestUpgradeXversion.pm>
Incidentally, just as a warning for anyone trying, this uses up a quite
a lot of disk space.
You would need several GB available.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-05-03 17:38:06 | Re: pg_upgrade and toasted pg_largeobject |
Previous Message | Stephen Frost | 2016-05-03 17:29:44 | Re: ALTER TABLE lock downgrades have broken pg_upgrade |