Hi, On 2025-03-18 10:04:41 -0400, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > I'm not quite sure what the best thing is to do is for the pg_upgrade > > tests in particular, and it may well be best to do as you propose for > > now and figure that out later. But I question whether just rerunning > > all of those tests with several different mode flags is the right > > thing to do. Why for example does 005_char_signedness.pl need to be > > checked under both --link and --clone? I would guess that there are > > one or maybe two tests in src/bin/pg_upgrade/t that needs to test > > --link and --clone and they should grow internal loops to do that > > (when supported by the local platform) and PG_UPGRADE_TEST_MODE should > > go in the garbage. > > +1 > > I'd be particularly allergic to running 002_pg_upgrade.pl multiple > times, as that's one of our most expensive tests, and I flat out > don't believe that expending that many cycles could be justified. > Surely we can test these modes sufficiently in some much cheaper and > more targeted way.
+1 It's useful to have coverage of as many object types as possible in pg_upgrade - hence 002_pg_upgrade.pl. It helps us to find problems in new code that didn't think about pg_upgrade. But that doesn't mean that it's a good idea to run all other pg_upgrade tests the same way, to the contrary - the cost is too high. Even leaving runtime aside, I have a hard time believing that --link, --clone, --swap benefit from running the same way as 002_pg_upgrade.pl - the implementation of those flags is on a lower level and works the same across e.g. different index AMs. I'd go so far as to say that 002_pg_upgrade.pl style testing actually makes it *harder* to diagnose problems related to things like --link, because there are no targeted tests, but just a huge set of things that maybe allow to infer some bug if you spend a lot of time. Greetings, Andres Freund
