On Sun, Dec 07, 2025 at 11:57:34PM -0500, Tom Lane wrote: > Nah, hold off till we have a discussion about whether the test is > correct to expect compatibility. We can afford to have a couple > of BF animals unhappy for a day or two while we come to a decision.
By the way, while looking at the buildfarm failures, I have noticed that something is wrong in my patch. Looking Makefile.global.in, USE_MODULE_DB is built based on REGRESS for the tests of src/test/modules/gin/. However things are inconsistent between meson and ./configure. For example, this host uses configure/make: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skimmer&dt=2025-12-08%2006%3A08%3A23 The database name is contrib_regression_gin_incomplete_splits, which points to the test gin_incomplete_split in src/test/modules/gin/, meaning that my patch would not work. In the meson case, we got this failure: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2025-12-08%2006%3A27%3A04 And here, the database name is regression_gin. When I looked at the buildfarm failures, I saw the regression_gin first, wrote a patch based on that. But the second one based on contrib_regression_gin_incomplete_splits was really puzzling me, until I've noticed that the difference was configure vs meson for the two hosts. So it seems to me that we have a second issue here, where meson relies on a "name" while configure uses the first value of "REGRESS". AdjustUpgrade.pm cannot know that it's dealing with one build method or the other. In order to make my previous patch work, we could use a DROP DATABASE IF EXISTS on both database names. That would work, but that feels grotty for the purpose of fixing things, especially as I don't see a point in keeping the test libraries across major upgrades.. -- Michael
signature.asc
Description: PGP signature
