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