Improve TAP tests of pg_upgrade for cross-version tests

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Improve TAP tests of pg_upgrade for cross-version tests
Date: 2022-05-24 06:03:28
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hi all,
(Adding Andrew Dunstan in CC.)

I have been toying with $subject, trying to improve the ways to test
pg_upgrade across different major versions as perl makes that easier.
The buildfarm does three things to allow such tests to work (see
- Apply a filter to the dumps generated to make them perfectly equal
as the set of regexps on the SQL dumps (removal of empty lines and
comments in the SQL dumps as arguments of a diff command).
- Apply diffs dumps to remove or modify objects, to avoid
inconsistencies, which is what upgrade_adapt.sql does in the tree.
- Add tweaks to the dump commands used, like --extra-float-digits=0
when testing with a version <= 11 as origin (aka c6f9464b in the
buildfarm client).

Attached is a basic patch to show what can be used to improve the TAP
tests of pg_upgrade in this area, with contents coming mostly from the
buildfarm client. The end picture would be to allow all those tests
to use the core code, rather than duplicating that in the buildfarm
client. This reduces a lot the amount of noise that can be seen when
comparing the dumps taken (the tests pass with v14) while remaining
simple, down to v11, so that could be a first step. There are a
couple of things where I am not sure how the buildfarm handles things,
but perhaps the dumps of installcheck have been tweaked to ignore such
cases? Here is an exhaustive list:
- multirange_type_name when using PG <= v13 as origin, for CREATE
- CREATE/ALTER PROCEDURE append IN to the list of parameters dumped,
when using PG <= v13 as origin.
moved from one command to the other.


Attachment Content-Type Size
0001-Add-more-filtering-capabilities-in-the-dumps.patch text/x-diff 4.8 KB


Browse pgsql-hackers by date

  From Date Subject
Next Message bucoo 2022-05-24 06:06:28 re: partition wise aggregate wrong rows cost
Previous Message 2022-05-24 05:33:50 RE: bogus: logical replication rows/cols combinations