Re: [PATCH] Fix pg_upgrade test from v10 - Mailing list pgsql-hackers

From Anton A. Melnikov
Subject Re: [PATCH] Fix pg_upgrade test from v10
Date
Msg-id 126b4480-359c-b745-a713-336ae96d1936@inbox.ru
Whole thread Raw
In response to Re: [PATCH] Fix pg_upgrade test from v10  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: [PATCH] Fix pg_upgrade test from v10  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
Hello!

On 02.06.2022 23:57, Andrew Dunstan wrote:

> 
> 1. There is no mention of why there's a change w.r.t. Cygwin and
> permissions checks. Maybe it's ok, but it seems off topic and is
> certainly not referred to in the patch submission.
> 
Thanks for the comments!
It was my error to change w.r.t. Cygwin. I've fixed it in the second 
version of the patch. But change in permissons check is correct. If we 
fix the error with initdb options, we've got the next one while testing 
upgrade from v10:
"files in PGDATA with permission != 640"
and the test.sh will end immediately.
The thing is that the default permissions have changed in v11+ due to 
this commit: 
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=c37b3d08ca6873f9d4eaf24c72a90a550970cbb8.
Changes of permissions checks in test.sh fix this error.

 > On 2022-06-01 We 21:37, Michael Paquier wrote:
 >> A node's pg_version is assigned via _set_pg_version() when creating it
 >> using PostgreSQL::Test::Cluster::new().  In order to make the
 >> difference with the set of initdb options to use when setting up the
 >> old node, it would be simpler to rely on that, no?  Version.pm is able
 >> to handle integer as well as string comparisons for the version
 >> strings.
 >
> 2. As Michael says, we should not be using perl's version module, we
> should be using the version object built into each
> PostgreSQL::Test::Cluster instance.
> 
Sure, very valuable note. Fixed it in the 2nd version of the patch attached.

Also find that i forgot to adjust initdb keys for new node in v15. So 
there was an error due to wal-segsize mismatch. Fixed it in the 2nd 
version too. And added patches for other versions.

 > The client buildfarm does not make use of the in-core facility, as it 
 > has its own module and logic to check after the case of cross-version 
 > upgrades (see PGBuild/Modules/TestUpgradeXversion.pm)..

Michael, thanks a lot for your 2c.

With best regards,

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

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: pgcon unconference / impact of block size on performance
Next
From: Matthias van de Meent
Date:
Subject: Re: Improving btree performance through specializing by key shape, take 2