Hi, On 2023-01-27 20:39:04 -0500, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > Tom, is there a reason we run the various sanity tests early-ish in the > > schedule? It does seem to reduce their effectiveness a bit... > > Originally, those tests were mainly needed to sanity-check the > hand-maintained initial catalog data, so it made sense to run them > early.
It's also kinda useful to have some basic validity testing early on, because if there's something wrong with the catalog values, it'll cause lots of issues later. > > Problems: > > - "Cross-check against pg_type entry" is far too strict about legal > > combinations > > of typstorage > > Perhaps, but it's enforcing policy about what we want in the > initial catalog data, not what is possible to support. True in generaly, but I don't think it matters much in this specific case. We don't gain much by forbidding 'e' -> 'x' mismatches, given that we allow 'x' -> 'p'. There's a lot more such cases in opr_sanity. There's a lot of tests in it that only make sense for validating the initial catalog contents. It might be useful to run a more lenient version of it later though. > So there's a bit of divergence of goals here too. Maybe we need to split up > the tests into initial-data-only tests (run early) and tests that should > hold for user-created objects too (run late)? Yea, I think so. A bit worried about the duplication that might require. But the *sanity tests also do also encode a lot of good cross-checks, that are somewhat easy to break in code (and / or have been broken in the past), so I think it's worth pursuing. Greetings, Andres Freund