Re: Extracting cross-version-upgrade knowledge from buildfarm client - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Extracting cross-version-upgrade knowledge from buildfarm client
Date
Msg-id Y8SDW1sGe+UWKsN1@paquier.xyz
Whole thread Raw
In response to Re: Extracting cross-version-upgrade knowledge from buildfarm client  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Extracting cross-version-upgrade knowledge from buildfarm client
List pgsql-hackers
On Sat, Jan 14, 2023 at 03:06:06PM -0500, Tom Lane wrote:
> I tried to use this to replace upgrade_adapt.sql, but failed so
> far because I couldn't figure out exactly how you're supposed
> to use 002_pg_upgrade.pl with an old source installation.
> It's not terribly well documented.

As in pg_upgrade's TESTING or the comments of the tests?

> In any case I think we
> need a bit more thought about that, because it looks like
> 002_pg_upgrade.pl thinks that you can supply any random dump
> file to serve as the initial state of the old installation;
> but neither what I have here nor any likely contents of
> upgrade_adapt.sql or the "custom filter" rules are going to
> work on databases that aren't just the standard regression
> database(s) of the old version.

Yeah, this code needs an extra push that I have not been able to
figure out yet, as we could recommend the creation of a dump with
installcheck-world and USE_MODULE_DB=1.  Perhaps a module is just
better at the end.

> I assume we should plan on reverting 9814ff550 (Add custom filtering
> rules to the TAP tests of pg_upgrade)?  Does that have any
> plausible use that's not superseded by this patchset?

Nope, this could just be removed if we finish by adding a module that
does exactly the same work.  If you are planning on committing the
module you have, i'd be happy to take care of a revert for this part.

+       # 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.

Is this module pluggable with 002_pg_upgrade.pl?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: test
Next
From: Tom Lane
Date:
Subject: Re: Extracting cross-version-upgrade knowledge from buildfarm client