Re: [BUG] pg_upgrade test fails from older versions. - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [BUG] pg_upgrade test fails from older versions.
Date
Msg-id Y6UVn1xZ5fx00qeP@paquier.xyz
Whole thread Raw
In response to Re: [BUG] pg_upgrade test fails from older versions.  ("Anton A. Melnikov" <aamelnikov@inbox.ru>)
Responses Re: [BUG] pg_upgrade test fails from older versions.  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
On Thu, Dec 22, 2022 at 09:59:18AM +0300, Anton A. Melnikov wrote:
> 2) v2-0002-Additional-dumps-filtering.patch

+       # Replace specific privilegies with ALL
+       $dump_contents =~ s/^(GRANT\s|REVOKE\s)(\S*)\s/$1ALL /mgx;
This should not be in 0002, I guess..

> Yes. Made a hook that allows to proceed an external text file with additional
> filtering rules and example of such file. Please take a look on it.
>
> With the best wishes,

Hmm.  0001 does a direct check on aclitem as data type used in an
attribute, but misses anything related to arrays, domains or even
composite types, not to mention that we'd miss uses of aclitems in
index expressions.

That's basically the kind of thing check_for_data_types_usage() does.
I am not sure that it is a good idea to provide a limited coverage if
we do that for matviews and indexes, and the complexity induced in
upgrade_adapt.sql is not really appealing either.  For now, I have
fixed the most pressing part for tables to match with the buildfarm
code that just drops the aclitem column rather than doing that for all
the relations that could have one.

The part on WITH OIDS has been addressed in its own commit down to
v12, removing the handling for matviews but adding one for foreign
tables where the operation is supported.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Avoid lost result of recursion (src/backend/optimizer/util/inherit.c)
Next
From: Vik Fearing
Date:
Subject: Re: Allow WindowFuncs prosupport function to use more optimal WindowClause options