Horton

Re: [BUG] pg_upgrade test fails from older versions.

Anton A. Melnikov <aamelnikov@inbox.ru>

View thread View on postgr.es
From: "Anton A. Melnikov" <aamelnikov@inbox.ru>
To: Michael Paquier <michael@paquier.xyz>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org
Date: 2022-12-27T12:26:10Z
Lists: pgsql-hackers 
Hello!

On 27.12.2022 08:44, Michael Paquier wrote:
> 
> It is worth noting that perlcritic was complaining here, as eval is
> getting used with a string.  I have spent a few days looking at that,
> and I really want a maximum of flexibility in the rules that can be
> applied so I have put a "no critic" rule, which is fine by me as this
> extra file is something owned by the user and it would apply only to
> cross-version upgrades.

I think it's a very smart decision. Thank you very match!

> So it looks like we are now done here..  With all these pieces in
> place in the tests, I don't see why it would not be possible to
> automate the cross-version tests of pg_upgrade.

I've checked the cross-upgrade test form 9.5+ to current master and
have found no problem with accuracy up to dumps filtering.
For cross-version tests automation one have to write additional
filtering rules in the external files.

I would like to try realize this, better in a separate thread.
If there are no other considerations could you close the corresponding
record on the January CF, please?


With the best wishes!

-- 
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Commits

  1. Add custom filtering rules to the TAP tests of pg_upgrade

  2. Switch query fixing aclitems in ~15 from O(N^2) to O(N) in upgrade_adapt.sql

  3. Update upgrade_adapt.sql to handle tables using aclitem as data type

  4. Fix some incorrectness in upgrade_adapt.sql on query for WITH OIDS