Re: Buildfarm's cross-version-upgrade tests

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Noah Misch <noah(at)leadboat(dot)com>
Subject: Re: Buildfarm's cross-version-upgrade tests
Date: 2020-12-30 21:28:44
Message-ID: 2a647872-5d72-6dc2-656b-0282c41b9c28@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 12/30/20 3:42 PM, Tom Lane wrote:
> I broke $SUBJECT again today by removing regress_putenv from
> regress.so. I don't really want to put it back, but that means
> we need a way to drop the corresponding SQL function from the
> old version's regression database before attempting an upgrade.
>
> Since I'd just seen Noah's commit 52202bb39 go by, I tried
> modifying src/bin/pg_upgrade/test.sh to do the drop, but that
> isn't helping. I recall now from prior discussions that we
> have to modify code that's embedded in the buildfarm client
> script to make this go. (I wonder what test scenario Noah had
> in mind, exactly.)
>
> Realizing that this has happened before and will happen again,
> I'm now wondering if we can't devise a fixup method that is
> controllable by committers and doesn't require a buildfarm
> client rollout to update. I'm thinking maybe we could extract
> the fixup logic from test.sh into a standalone SQL script that's
> part of the regular source tree so it can be updated by committers,
> and then both test.sh and the buildfarm script could invoke it.
> Maybe that won't work for some reason, but I'd sure like to find
> some way of handling this without making you get involved every time.
>
>

Well, it's not hugely onerous, although it does seem to have happened a
bit more lately than once it used to. Basically, there are two sets of
adjustments. First there are the things we do when we're saving a
cluster for later upgrade testing. These can be found at lines 238 - 300
of the module (see
<https://github.com/PGBuildFarm/client-code/blob/master/PGBuild/Modules/TestUpgradeXversion.pm>).
Then, when it comes time to do an upgrade test, we make a copy of the
cluster and make further adjustments depending on the target version as
well as the source version. See lines 363 - 496. Some of this is a bit
more complicated because we test all the way back to 9.2, even though
it's past EOL.

It seems reasonable to want to institutionalize this knowledge. I'll see
if I can extract it into one or two perl scripts suitable for inclusion
in core code.

I'll try to fix the test for the latest breakage shortly.

cheers

andrew

--

Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2020-12-30 21:38:59 Re: [PATCH] Simplify permission checking logic in user.c
Previous Message Simon Riggs 2020-12-30 21:23:19 Re: Reloptions for table access methods