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 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.



Attachment: upgrade_dump_diff.tgz
Description: Unix tar archive

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to