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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Extracting cross-version-upgrade knowledge from buildfarm client
Date: 2023-01-15 23:02:07
Message-ID: 1746620.1673823727@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(at)paquier(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-01-15 23:03:20 Re: The documentation for storage type 'plain' actually allows single byte header
Previous Message Michael Paquier 2023-01-15 22:51:07 Re: Extracting cross-version-upgrade knowledge from buildfarm client