Re: pg_upgrade test for binary compatibility of core data types

Justin Pryzby <pryzby@telsasoft.com>

From: Justin Pryzby <pryzby@telsasoft.com>

To: Tomas Vondra <tomas.vondra@2ndquadrant.com>

Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, buschmann@nidsa.net, pgsql-hackers@lists.postgresql.org

Date: 2020-12-27T19:07:29Z

Lists: pgsql-bugs, pgsql-hackers

Commits

Same data as JSON: 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

v3-0001-WIP-pg_upgrade-test.sh-changes-needed-to-allow-te.patch (text/x-diff)

On Wed, Dec 16, 2020 at 11:22:23AM -0600, Justin Pryzby wrote:
> On Sun, Dec 06, 2020 at 12:02:48PM -0600, Justin Pryzby wrote:
> > I meant to notice if the binary format is accidentally changed again, which was
> > what happened here:
> > 7c15cef86 Base information_schema.sql_identifier domain on name, not varchar.
> > 
> > I added a table to the regression tests so it's processed by pg_upgrade tests,
> > run like:
> > 
> > | time make -C src/bin/pg_upgrade check oldsrc=`pwd`/11 oldbindir=`pwd`/11/tmp_install/usr/local/pgsql/bin
> 
> Per cfbot, this avoids testing ::xml (support for which may not be enabled)
> And also now tests oid types.
> 
> I think the per-version hacks should be grouped by logical change, rather than
> by version.  Which I've started doing here.

rebased on 6df7a9698bb036610c1e8c6d375e1be38cb26d5f

-- 
Justin