Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andrew Dunstan <andrew@dunslane.net>, pgsql-hackers@lists.postgresql.org
Date: 2023-01-15T23:02:07Z
Lists: pgsql-hackers 
Michael Paquier <michael@paquier.xyz> writes:
> On Sat, Jan 14, 2023 at 03:06:06PM -0500, Tom Lane wrote:
> +       # Can't upgrade aclitem in user tables from pre 16 to 16+.
> +       _add_st($result, 'regression',
> +               'alter table public.tab_core_types drop column aclitem');

> Could you just use a DO block here to detect tables with such
> attributes, like in upgrade_adapt.sql, rather than dropping the table
> from the core tests?  That's more consistent with the treatment of
> WITH OIDS.

I guess, but it seems like make-work as long as there's just the one
column.

> Is this module pluggable with 002_pg_upgrade.pl?

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.

			regards, tom lane

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.