Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
Date: 2021-12-16 02:51:55
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Wed, Dec 15, 2021 at 10:47:24AM +0900, Michael Paquier wrote:
> Missed that, thanks! I'll think about all that a bit more before
> sending a long-overdue rebased version.

Okay, here is finally a rebase of this patch, where I have fixed a
couple of existing issues, and I have extended the patch to the point
where the support range is what I expect should be. In short:
- Added support for MSVC for the TAP test. I have considered making
upgradecheck silent, but after thinking about it I have just filtered
pg_upgrade from bincheck, and simplified upgradecheck to launch the
new test. It is simple to switch from one approach to another. This
shaves some code in
- Fixed a set of issues with various chdir commands in the previous
patches. The command of pg_regress has been tweaked so as all results
are part of src/bin/pg_upgrade/. Any logs generated by pg_upgrade
stay in this location, same way as HEAD.
- Adapted to the new modules of src/test/perl/.
- Support for cross-upgrades now uses upgrade_adapt.sql (I have sent a
patch for the buildfarm client about that yesterday actually), same
way as on HEAD. Like HEAD, attempting to use the
cross-version HEAD causes diffs between the old and the new dumps.
But there is nothing new here. This could be improved more but the
attached does already a lot.
- Like the previous versions, this supports two modes when setting up
the to-be-upgraded cluster: setup things from an old dump or use
pg_regress. The buildfarm does the former for upgrades down to 9.2.
The core code does the latter.

I may have missed one thing or two, but I think that's pretty much
what we should be looking for to do the switch to TAP in terms of

Attachment Content-Type Size
v4-0001-Switch-tests-of-pg_upgrade-to-use-TAP.patch text/x-diff 28.1 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message 2021-12-16 02:53:44 RE: Allow escape in application_name
Previous Message Thomas Munro 2021-12-16 02:44:43 Apple's ranlib warns about protocol_openssl.c