Running pg_upgrade Version 11

On Tue, Nov 06, 2018 at 04:27:35PM +1100, rob stone wrote:

Logged in as user postgres and postgres owns the files created by
initdb, so is this a permissions problem or am I having a brain fade?

Having 0600 as umask for those files is normal. Don't you have more
logs about the error? You should not see this error, except if data_v10
is not a data folder initialized correctly, so perhaps you messed up
something in your environment?
--
Michael

On 11/5/18 9:27 PM, rob stone wrote:

Hello,

Trying to run pg_upgrade from version 10 to version 11 on the test
server and pulling the following error:-

could not open version file: /home/postgres/testing/data_v10/PG_VERSION
Failure, exiting

O/S is:- Debian 4.18.10-2 (2018-11-02) x86_64 GNU/Linux

Running pg_upgrade as user postgres.

These are the permissions on the version 10 file:-

-rw------- 1 postgres postgres 3 Mar 23 2018 PG_VERSION

These are the permissions on the version 11 file:-

-rw------- 1 postgres postgres 3 Nov 6 14:50 PG_VERSION

This is the command being run:-

/usr/lib/postgresql/11/bin/pg_upgrade -b /usr/lib/postgresql/10/bin -B
/usr/lib/postgresql/11/bin -d /home/postgres/testing/data_v10 -D
/home/postgres/testing/data_v11

Logged in as user postgres and postgres owns the files created by
initdb, so is this a permissions problem or am I having a brain fade?

Is:

/home/postgres/testing/data_v10/

the correct path to the data directory?

What happens if you add?:

-U postgres

Maybe there is a PGUSER env variable set that is not postgres.

TIA,
Rob

--
Adrian Klaver
adrian.klaver@aklaver.com

On Tue, 2018-11-06 at 15:17 +0900, Michael Paquier wrote:

On Tue, Nov 06, 2018 at 04:27:35PM +1100, rob stone wrote:

Logged in as user postgres and postgres owns the files created by
initdb, so is this a permissions problem or am I having a brain
fade?

Having 0600 as umask for those files is normal. Don't you have more
logs about the error? You should not see this error, except if
data_v10
is not a data folder initialized correctly, so perhaps you messed up
something in your environment?
--
Michael

Problem caused by my eyesight.
A colleague pointed out the typo in the argument to the -d parameter.
Working as intended.

Sorry for the noise. My apologies.

Thanks,
Robert

On 11/06/2018 06:30 PM, rob stone wrote:

On Tue, 2018-11-06 at 15:17 +0900, Michael Paquier wrote:

On Tue, Nov 06, 2018 at 04:27:35PM +1100, rob stone wrote:

Logged in as user postgres and postgres owns the files created by
initdb, so is this a permissions problem or am I having a brain
fade?

Having 0600 as umask for those files is normal. Don't you have more
logs about the error? You should not see this error, except if
data_v10
is not a data folder initialized correctly, so perhaps you messed up
something in your environment?
--
Michael

Problem caused by my eyesight.
A colleague pointed out the typo in the argument to the -d parameter.
Working as intended.

That's why I like to line up my statements

/usr/lib/postgresql/11/bin/pg_upgrade \
-b /usr/lib/postgresql/10/bin \
-B /usr/lib/postgresql/11/bin \
-d /home/postgres/testing/data_v10 \
-D /home/postgres/testing/data_v11

--
Angular momentum makes the world go 'round.

On Wed, Nov 7, 2018 at 11:30:18AM +1100, rob stone wrote:

On Tue, 2018-11-06 at 15:17 +0900, Michael Paquier wrote:

On Tue, Nov 06, 2018 at 04:27:35PM +1100, rob stone wrote:

Logged in as user postgres and postgres owns the files created by
initdb, so is this a permissions problem or am I having a brain
fade?

Having 0600 as umask for those files is normal. Don't you have more
logs about the error? You should not see this error, except if
data_v10
is not a data folder initialized correctly, so perhaps you messed up
something in your environment?
--
Michael

Problem caused by my eyesight.
A colleague pointed out the typo in the argument to the -d parameter.
Working as intended.

Should the error message be improved?

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +