Re: pg_upgrade automatic testing
От | Bruce Momjian |
---|---|
Тема | Re: pg_upgrade automatic testing |
Дата | |
Msg-id | 201109031512.p83FCCH22069@momjian.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade automatic testing (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: