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: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, 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: 2022-02-16 04:58:10
Message-ID: YgyEYkbf/
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Tue, Feb 15, 2022 at 01:02:41PM +0900, Michael Paquier wrote:
> Hmm. At the end of the day, I am wondering whether we should not give
> up entirely on the concept of running the regression tests on older
> branches in the TAP script of a newer branch. pg_regress needs to
> come from the old source tree, meaning that we would most likely need
> to maintain a set of compatibility tweaks that would most probably
> rot over the time, and the buildfarm only cares about the possibility
> to set up old instances by loading dumps rather than running
> pg_regress. This would also make the switch to TAP much easier (no
> need for the extra createdb or --locale AFAIK). So attempting to
> maintain all that is going to be a PITA in the long term, and there is
> nothing running that automatically anyway.
> There is also the extra requirement to adjust dump files, but that's
> independent of setting up the old instance to upgrade, and I don't
> really plan to tackle that as of this thread (note that the buildfarm
> client has extra tweaks regarding that).
> Any thoughts about that?

I have been looking at how much simplicity this brings, and I have to
admit that it is tempting to just support the loading of dumps when
setting up the old instance to upgrade from. We'd still need to do an
extra effort in terms of cleaning up the diffs for the dump of the old
instance with older versions once/if this is plugged into the
buildfarm, but that could be addressed later depending on the versions
that need to be covered.

Attachment Content-Type Size
v9-0001-Fix-sanity-check-for-PGHOST-ADDR-in-pg_upgrade-wi.patch text/x-diff 1.6 KB
v9-0002-Switch-tests-of-pg_upgrade-to-use-TAP.patch text/x-diff 27.6 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2022-02-16 04:59:11 Re: USE_BARRIER_SMGRRELEASE on Linux?
Previous Message Kasahara Tatsuhito 2022-02-16 04:25:09 Re: Small and unaffected typo in pg_logical_slot_get_changes_guts()