From: Justin Pryzby <pryzby@telsasoft.com>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>
Cc: buschmann@nidsa.net
Cc: pgsql-hackers@lists.postgresql.org
Subject: pg_upgrade test for binary compatibility of core data types
Date: Sun, 6 Dec 2020 12:02:48 -0600
Message-ID: <20201206180248.GI24052@telsasoft.com> (raw)
In-Reply-To: <20191015070725.csmdmdvrlb6klwkg@development>
References: <1542.1570738460@sss.pgh.pa.us>
<20191010204022.6hiiubm2cueu3ghk@development>
<20191013001032.lqrn4kqaovhrf77l@development>
<17717.1570991208@sss.pgh.pa.us>
<20191013203848.2eksimmpux3546wr@development>
<27596.1571062600@sss.pgh.pa.us>
<20191014163538.cqn6j4cl7s2mk2yz@development>
<20191015001817.zei45apgpu5dzngr@development>
<20191015044118.GO3599@telsasoft.com>
<20191015070725.csmdmdvrlb6klwkg@development>
I'm finally returning to this 14 month old thread:
(was: Re: BUG #16045: vacuum_db crash and illegal memory alloc after pg_upgrade from PG11 to PG12)
On Tue, Oct 15, 2019 at 09:07:25AM +0200, Tomas Vondra wrote:
> On Mon, Oct 14, 2019 at 11:41:18PM -0500, Justin Pryzby wrote:
> >
> > Perhaps it'd be worth creating a test for on-disk format ?
> >
> > Like a table with a column for each core type, which is either SELECTed from
> > after pg_upgrade, or pg_dump output compared before and after.
>
> IMO that would be useful - we now have a couple of these checks for
> different data types (line, unknown, sql_identifier), with a couple of
> combinations each. And I've been looking if we do similar pg_upgrade
> tests, but I haven't found anything. I mean, we do pg_upgrade the
> cluster used for regression tests, but here we need to test a number of
> cases that are meant to abort the pg_upgrade. So we'd need a number of
> pg_upgrade runs, to test that.
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
I checked that if I cherry-pick 0002 to v11, and comment out
old_11_check_for_sql_identifier_data_type_usage(), then pg_upgrade/test.sh
detects the original problem:
pg_dump: error: Error message from server: ERROR: invalid memory alloc request size 18446744073709551613
I understand the buildfarm has its own cross-version-upgrade test, which I
think would catch this on its own.
These all seem to complicate use of pg_upgrade/test.sh, so 0001 is needed to
allow testing upgrade from older releases.
e78900afd217fa3eaa77c51e23a94c1466af421c Create by default sql/ and expected/ for output directory in pg_regress
40b132c1afbb4b1494aa8e48cc35ec98d2b90777 In the pg_upgrade test suite, don't write to src/test/regress.
fc49e24fa69a15efacd5b8958115ed9c43c48f9a Make WAL segment size configurable at initdb time.
c37b3d08ca6873f9d4eaf24c72a90a550970cbb8 Allow group access on PGDATA
da9b580d89903fee871cf54845ffa2b26bda2e11 Refactor dir/file permissions
--
Justin
Attachments:
[text/x-diff] 0001-WIP-pg_upgrade-test.sh-changes-needed-to-allow-testi.patch (0B, ../20201206180248.GI24052@telsasoft.com/2-0001-WIP-pg_upgrade-test.sh-changes-needed-to-allow-testi.patch)
download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: pryzby@telsasoft.com, tomas.vondra@2ndquadrant.com, tgl@sss.pgh.pa.us, andres@anarazel.de, buschmann@nidsa.net, pgsql-hackers@lists.postgresql.org
Subject: Re: pg_upgrade test for binary compatibility of core data types
In-Reply-To: <20201206180248.GI24052@telsasoft.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox