Re: ALTER TABLE lock downgrades have broken pg_upgrade
От | Andrew Dunstan |
---|---|
Тема | Re: ALTER TABLE lock downgrades have broken pg_upgrade |
Дата | |
Msg-id | 5728E0FD.8000501@dunslane.net обсуждение исходный текст |
Ответ на | Re: ALTER TABLE lock downgrades have broken pg_upgrade (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: ALTER TABLE lock downgrades have broken pg_upgrade
|
Список | 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@2ndquadrant.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
В списке pgsql-hackers по дате отправления: