Buildfarm's cross-version-upgrade tests

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Noah Misch <noah(at)leadboat(dot)com>
Subject: Buildfarm's cross-version-upgrade tests
Date: 2020-12-30 20:42:47
Message-ID: 2403475.1609360967@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2020-12-30 20:52:46 crash recovery vs partially written WAL
Previous Message Isaac Morland 2020-12-30 20:17:47 Re: Let people set host(no)ssl settings from initdb