Horton

Re: Extracting cross-version-upgrade knowledge from buildfarm client

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, pgsql-hackers@lists.postgresql.org
Date: 2023-01-15T23:38:58Z
Lists: pgsql-hackers 
On Sun, Jan 15, 2023 at 06:02:07PM -0500, Tom Lane wrote:
> I guess, but it seems like make-work as long as there's just the one
> column.

Well, the query is already written, so I would use that, FWIW.

> I did find that 002_pg_upgrade.pl could load it.  I got stuck at
> the point of trying to test things, because I didn't understand
> what the test process is supposed to be for an upgrade from a
> back branch.  For some reason I thought that 002_pg_upgrade.pl
> could automatically create the old regression database, but
> now I see that's not implemented.

test.sh did that, until I noticed that we need to worry about
pg_regress from the past branches to be compatible in the script
itself because we need to run it in the old source tree.  This makes
the whole much more complicated to maintain, especially with the
recent removal of input/ and output/ folders in the regression tests
:/ 
--
Michael

Commits

  1. Compare only major versions in AdjustUpgrade.pm

  2. Get rid of the "new" and "old" entries in a view's rangetable.

  3. Create common infrastructure for cross-version upgrade testing.