On Thu, Feb 22, 2024 at 3:03 PM Daniel Gustafsson <daniel@yesql.se> wrote:
>
> > 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
regresstest and have the pg_dump test reuse that, but then that would make the regress test run a bit longer. Is that
abetter tradeoff?
>
> Something this expensive seems like what PG_TEST_EXTRA is intended for, we
> already have important test suites there.
That's ok with me.
>
> 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.
Somebody looking for dump/restore tests wouldn't search
src/bin/pg_upgrade, I think. However if more people think we should
just add this test 002_pg_upgrade.pl, I am fine with it.
>
> 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.
If comparison of C to A fails, we wouldn't know which step fails. I
would rather compare outputs of each step separately.
--
Best Wishes,
Ashutosh Bapat
