Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
Date
Msg-id YgyEYkbf/M6Q9C+F@paquier.xyz
Whole thread Raw
In response to Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
List 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.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Kasahara Tatsuhito
Date:
Subject: Re: Small and unaffected typo in pg_logical_slot_get_changes_guts()
Next
From: Nathan Bossart
Date:
Subject: Re: USE_BARRIER_SMGRRELEASE on Linux?