On 5/21/21 5:43 PM, Andres Freund wrote: > Hi, > > On 2021-05-20 09:16:50 -0400, Andrew Dunstan wrote: >> We certainly shouldn't want that. But we do need it for the target >> unless we wipe out everything in the source that refers to it. > Is there a reason not to go for the wipe? I don't think the type of > functions we have in regress.so are necessarily ones we'd even expect to > work in the next version? > > Here's references to explicit files I see after an installcheck: > [...] > Testing the pg_upgrade path for these doesn't seem to add meaningful > coverage, and several seem likely to cause problems across versions? >
Possibly. My approach generally has been to upgrade as much as possible, only removing things known to have issues. However, this discussion does raise some deeper points. The first is that while we test that pg_upgrade passes we don't actually test that everything is still working. So for example if an SQL function in a loaded module changed signature from one version to another we might never discover it. So one area that needs development is some post-upgrade tests. Second, we are treating the regression databases as a suitable base for testing pg_upgrade. But they aren't designed for that, they are designed for completely different purposes, and we're really just using them out of laziness because they are something we happen to have on hand. Maybe we should develop a suitable purpose-designed upgrade database for testing. There are things that we have found in the past that caused issues we didn't detect because they weren't covered in the upgraded databases. Both of these seem like possibly good Summer of Code or intern projects. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
