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

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