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 Y5/XgkzX2LVe7PvZ@paquier.xyz
Whole thread Raw
In response to Re: [BUG] pg_upgrade test fails from older versions.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [BUG] pg_upgrade test fails from older versions.  ("Anton A. Melnikov" <aamelnikov@inbox.ru>)
List pgsql-hackers
On Sun, Dec 18, 2022 at 08:56:48PM -0500, Tom Lane wrote:
> "Anton A. Melnikov" <aamelnikov@inbox.ru> writes:
>> 2) In 60684dd83 and b5d63824 there are two changes in the set of specific privileges.
>> The thing is that in the privileges.sql test there is REVOKE DELETE command
>> which becomes pair of REVOKE ALL and GRANT all specific privileges except DELETE
>> in the result dump. Therefore, any change in the set of specific privileges will lead to
>> a non-zero dumps diff.
>> To avoid this, i propose to replace any specific GRANT and REVOKE in the result dumps with ALL.
>> This also made in the patch attached.
>
> Isn't that likely to mask actual bugs?

+   # Replace specific privilegies with ALL
+   $dump_contents =~ s/^(GRANT\s|REVOKE\s)(\S*)\s/$1ALL /mgx;
Yes, this would silence some diffs in the dumps taken from the old and
the new clusters.  It seems to me that it is one of the things where
the original dumps have better be tweaked, as this does not cause a
hard failure when running pg_upgrade.

While thinking about that, an extra idea popped in my mind as it may
be interesting to be able to filter out some of the diffs in some
contexts.  So what about adding in 002_pg_upgrade.pl a small-ish hook
in the shape of a new environment variable pointing to a file adds
some custom filtering rules?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [BUG] pg_upgrade test fails from older versions.
Next
From: Michael Paquier
Date:
Subject: Re: [PATCH] random_normal function