Re: ALTER TABLE lock downgrades have broken pg_upgrade

On 05/03/2016 01:33 PM, Andrew Dunstan wrote:
>
>
> 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.
>
>

And if this is of any use, here are the dump differences from every live
version to git tip, as of this morning.

cheers

andrew