Re: pg_upgrade test for binary compatibility of core data types
Michael Paquier <michael@paquier.xyz>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Move into separate file all the SQL queries used in pg_upgrade tests
- 1924d508c335 10.20 landed
- 0e603b75c434 11.15 landed
- b6e525648d72 12.10 landed
- fae5f08e1719 13.6 landed
- b6dac98b0561 14.2 landed
- 0df9641d3905 15.0 landed
-
Add table to regression tests for binary-compatibility checks in pg_upgrade
- a9993416f80f 12.10 landed
- 755f04c72ef1 13.6 landed
- cf3d79aa31f2 14.2 landed
- 835bcba8b8d7 15.0 landed
-
Fix tests of pg_upgrade across different major versions
- afa09e4a9af6 12.9 landed
- 2a8dee6a67cc 13.5 landed
- f4e1c8892b9e 14.1 landed
- fa66b6dee084 15.0 landed
-
Multirange datatypes
- 6df7a9698bb0 14.0 cited
-
Work around cross-version-upgrade issues created by commit 9e38c2bb5.
- 97f73a978fc1 14.0 cited
-
Declare assorted array functions using anycompatible not anyelement.
- 9e38c2bb5093 14.0 cited
-
Remove factorial operators, leaving only the factorial() function.
- 76f412ab3105 14.0 cited
-
Create by default sql/ and expected/ for output directory in pg_regress
- e78900afd217 14.0 cited
-
Add missing include to pg_upgrade/version.c
- bc3a94dc0005 9.4.25 landed
- 984aa0ede1d2 9.5.20 landed
- e09ab32a2205 9.6.16 landed
-
Improve the check for pg_catalog.line data type in pg_upgrade
- 235a52ca0f26 9.4.25 landed
- f57b01dd75ee 9.5.20 landed
- 0a643de08715 9.6.16 landed
- 2218fdca496b 10.11 landed
- a970b6cdebd1 11.6 landed
- ebb4caa9120d 12.1 landed
- 8d48e6a7240c 13.0 landed
-
Improve the check for pg_catalog.unknown data type in pg_upgrade
- e86ece22114d 10.11 landed
- d071a2539ff4 11.6 landed
- a8e49ae0c381 12.1 landed
- a524f50d0fc6 13.0 landed
-
Check for tables with sql_identifier during pg_upgrade
- eaf900e842ab 12.1 landed
- 0ccfc2822366 13.0 landed
-
pg_upgrade: clarify the database names in error files
- 1634d361577a 13.0 cited
-
In the pg_upgrade test suite, don't write to src/test/regress.
- 40b132c1afbb 12.0 cited
-
Allow group access on PGDATA
- c37b3d08ca68 11.0 cited
-
Refactor dir/file permissions
- da9b580d8990 11.0 cited
-
Remove unused functions in regress.c.
- db3af9feb19f 11.0 cited
-
Make WAL segment size configurable at initdb time.
- fc49e24fa69a 11.0 cited
-
Fix bit-rot in pg_upgrade's test.sh, and improve documentation.
- 5bab1985dfc2 10.0 cited
Attachments
- upgrade-test-fixes.patch (text/x-diff) patch
On Fri, Oct 01, 2021 at 04:58:41PM +0900, Michael Paquier wrote: > I was looking at this CF entry, and what you are doing in 0004 to move > the tweaks from pg_upgrade's test.sh to a separate SQL script that > uses psql's meta-commands like \if to check which version we are on is > really interesting. The patch does not apply anymore, so this needs a > rebase. The entry has been switched as waiting on author by Tom, but > you did not update it after sending the new versions in [1]. I am > wondering if we could have something cleaner than just a set booleans > as you do here for each check, as that does not help with the > readability of the tests. And so, I am back at this thread, looking at the set of patches proposed from 0001 to 0004. The patches are rather messy and mix many things and concepts, but there are basically four things that stand out: - test.sh is completely broken when using PG >= 14 as new version because of the removal of the test tablespace. Older versions of pg_regress don't support --make-tablespacedir so I am fine to stick a couple of extra mkdirs for testtablespace/, expected/ and sql/ to allow the script to work properly for major upgrades as a workaround, but only if we use an old version. We need to do something here for HEAD and REL_14_STABLE. - The script would fail when using PG <= 11 as old version because of WITH OIDS relations. We need to do something down to REL_12_STABLE. I did not like much the approach taken to stick 4 ALTER TABLE queries though (the patch was actually failing here for me), so instead I have borrowed what the buildfarm has been doing with a DO block. That works fine, and that's more portable. - Not using --extra-float-digits with PG <= 11 as older version causes a bunch of diffs in the dumps, making the whole unreadable. The patch was doing that unconditionally for *all version*, which is not good. We should only do that on the versions that need it, and we know the old version number before taking any dumps so that's easy to check. - The addition of --wal-segsize and --allow-group-access breaks the script when using PG < 10 at initdb time as these got added in 11. With 10 getting EOL'd next year and per the lack of complaints, I am not excited to do anything here and I'd rather leave this out so as we keep coverage for those options across *all* major versions upgraded from 11~. The buildfarm has tests down to 9.2, but for devs my take is that this is enough for now. This is for the basics in terms of fixing test.sh and what should be backpatched. In this aspect patches 0001 and 0002 were a bit incorrect. I am not sure that 0003 is that interesting as designed as we would miss any new core types introduced. 0004 is something I'd like to get done on HEAD to ease the move of the pg_upgrade tests to TAP, but it could be made a bit easier to read by not having all those oldpgversion_XX_YY flags grouped together for one. So I am going to rewrite portions of it once done with the above. For now, attached is a patch to address the issues with test.sh that I am planning to backpatch. This fixes the facility on HEAD, while minimizing the diffs between the dumps. We could do more, like a s/PROCEDURE/FUNCTION/ but that does not make the diffs really unreadable either. I have only tested that on HEAD as new version down to 11 as the oldest version per the business with --wal-segsize. This still needs tests with 12~ as new version though, which is boring but not complicated at all :) -- Michael