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 (alvhe...@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 thatexercises the pg_upgrade test from every supported version to the lateststable 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.
Description: Unix tar archive
-- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers