Peter Eisentraut wrote: > But if you think about it, it doesn't really test pg_upgrade, it tests > pg_dump. So the test could just as well be moved to src/bin/pg_dump/ > and be labeled "pg_dump smoke test" or whatever. (Minor detail: The bug > fix above involved the --binary-upgrade flag, so it is somewhat > pg_upgrade related.) > > A real pg_upgrade test suite should naturally upgrade across binary > incompatible versions. The real question is how you develop a useful > test input. Most pg_upgrade issues are not bugs of omission or > regression but unexpected corner cases discovered with databases of > nontrivial usage patterns. (The recent one related to upgrade from 8.3 > is an exception.) Because the basic premise of pg_upgrade is, dump and > restore the schema, move over the files, that's it, and the rest of the > code is workarounds for obscure details that are difficult to anticipate > let alone test for.
You might want to read my blog entry on why pg_upgrade relies so much on external tools: http://momjian.us/main/blogs/pgblog/2011.html#June_15_2011_2 -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers