Re: Test to dump and restore objects left behind by regression
От | Daniel Gustafsson |
---|---|
Тема | Re: Test to dump and restore objects left behind by regression |
Дата | |
Msg-id | 31E00647-67E3-4541-AE6B-2104F4EB8222@yesql.se обсуждение исходный текст |
Ответ на | Re: Test to dump and restore objects left behind by regression (Peter Eisentraut <peter@eisentraut.org>) |
Ответы |
Re: Test to dump and restore objects left behind by regression
|
Список | pgsql-hackers |
> On 22 Feb 2024, at 10:16, Peter Eisentraut <peter@eisentraut.org> wrote: > We have somewhat relied on the pg_upgrade test to provide this testing, but we have recently discovered that the dumpsin binary-upgrade mode are different enough to not test the normal dumps well. > > Yes, this test is a bit expensive. We could save some time by doing the first dump at the end of the normal regress testand have the pg_dump test reuse that, but then that would make the regress test run a bit longer. Is that a better tradeoff? Something this expensive seems like what PG_TEST_EXTRA is intended for, we already have important test suites there. But. We know that the cluster has an interesting state when the pg_upgrade test starts, could we use that to make a dump/restore test before continuing with testing pg_upgrade? It can be argued that pg_upgrade shouldn't be responsible for testing pg_dump, but it's already now a pretty important testcase for pg_dump in binary upgrade mode so it's that far off. If pg_dump has bugs then pg_upgrade risks subtly breaking. When upgrading to the same version, we could perhaps also use this to test a scenario like: Dump A, restore into B, upgrade B into C, dump C and compare C to A. -- Daniel Gustafsson
В списке pgsql-hackers по дате отправления: