Re: pg_upgrade test for binary compatibility of core data types
Andrew Dunstan <andrew@dunslane.net>
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
On 9/13/21 9:20 AM, Andrew Dunstan wrote: > On 9/12/21 2:41 PM, Andrew Dunstan wrote: >> On 9/11/21 8:51 PM, Justin Pryzby wrote: >>> @Andrew: did you have any comment on this part ? >>> >>> |Subject: buildfarm xversion diff >>> |Forking https://www.postgresql.org/message-id/20210328231433.GI15100@telsasoft.com >>> | >>> |I gave suggestion how to reduce the "lines of diff" metric almost to nothing, >>> |allowing a very small "fudge factor", and which I think makes this a pretty >>> |good metric rather than a passable one. >>> >> Somehow I missed that. Looks like some good suggestions. I'll >> experiment. (Note: we can't assume the presence of sed, especially on >> Windows). >> >> > I tried with the attached patch on crake, which tests back as far as > 9.2. Here are the diff counts from HEAD: > > > andrew@emma:HEAD $ grep -c '^[+-]' dumpdiff-REL9_* dumpdiff-REL_1* > dumpdiff-HEAD > dumpdiff-REL9_2_STABLE:514 > dumpdiff-REL9_3_STABLE:169 > dumpdiff-REL9_4_STABLE:185 > dumpdiff-REL9_5_STABLE:221 > dumpdiff-REL9_6_STABLE:11 > dumpdiff-REL_10_STABLE:11 > dumpdiff-REL_11_STABLE:73 > dumpdiff-REL_12_STABLE:73 > dumpdiff-REL_13_STABLE:73 > dumpdiff-REL_14_STABLE:0 > dumpdiff-HEAD:0 > > > I've also attached those non-empty dumpdiff files for information, since > they are quite small. > > > There is still work to do, but this is promising. Next step: try it on > Windows. > > It appears to do the right thing on Windows. yay! We probably need to get smarter about the heuristics, though, e.g. by taking into account the buildfarm options and the platform. It would also help a lot if we could make vcregress.pl honor USE_MODULE_DB. That's on my TODO list, but it just got a lot higher priority. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com