Re: Upgrade problem

2023-09-12 Thread Adrian Klaver

On 9/12/23 03:51, Graeme wrote:

On 11/09/2023 17:04, Graeme wrote:






Ta

Graeme Gemmill


Tom, Adrian, Ray: thanks for your comments. I see the problem now, 
trying to gat a Mga8 module to link against Mga9 libraries. I suspecy a 
carefully placed sym-link or two will sort the problem.




I'm thinking you would be better off doing a pg_dumpall of the old 
cluster and psql  -f dump_file.sql on the new 
cluster per:


https://www.postgresql.org/docs/current/app-pg-dumpall.html

--
Adrian Klaver
adrian.kla...@aklaver.com





Re: Upgrade problem

2023-09-12 Thread Graeme

On 11/09/2023 17:04, Graeme wrote:


Preparing to upgrade my small cluster from Mageia 8/Pg 9 to Mageia 
9/Pg 15. I'm at the point of running pg_upgrade but have received 
anerror message:


/mga8/usr/bin/postgres: error while loading shared libraries: 
libssl.so.1.1: cannot open shared object file: No such file or directory

no data was returned by command ""/mga8/usr/bin/postgres" -V"

However:

[root@bach lib64]# cd /mga8/usr/lib64
[root@bach lib64]# ls -l|grep libssl
-rwxr-xr-x  1 root root  426192 Jul  5 23:07 libssl3.so*
lrwxrwxrwx  1 root root  13 Jun  1 09:35 libssl.so -> 
libssl.so.1.1*

-r-xr-xr-x  1 root root  442424 Feb 27  2021 libssl.so.1.0.0*
-rwxr-xr-x  1 root root  666496 Jun  1 09:36 libssl.so.1.1*

Can someone suggest my next move please?

Ta

Graeme Gemmill


Tom, Adrian, Ray: thanks for your comments. I see the problem now, 
trying to gat a Mga8 module to link against Mga9 libraries. I suspecy a 
carefully placed sym-link or two will sort the problem.


Re: Upgrade problem

2023-09-12 Thread Peter J. Holzer
On 2023-09-11 17:04:54 +0100, Graeme wrote:
> Preparing to upgrade my small cluster from Mageia 8/Pg 9 to Mageia 9/Pg 15. 
> I'm
> at the point of running pg_upgrade but have received anerror message:
> 
> /mga8/usr/bin/postgres: error while loading shared libraries: libssl.so.1.1:
> cannot open shared object file: No such file or directory
> no data was returned by command ""/mga8/usr/bin/postgres" -V"
> 
> However:
> 
> [root@bach lib64]# cd /mga8/usr/lib64

I'm not familiar with the Mageia update process, but the paths look
strange, Is it normal that old binaries and libraries are moved into a
directory named after the old version (I assume "mga8" is short for
Mageia version 8") or is this something you have done?

In any case, /mga8/usr/lib64 would not normally be on the library
search path, Have you somehow told /mga8/usr/bin/postgres to look there?

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature


Re: Upgrade problem

2023-09-11 Thread Ray O'Donnell

On 11/09/2023 17:33, Graeme wrote:

On 11/09/2023 17:13, Adrian Klaver wrote:

On 9/11/23 09:04, Graeme wrote:
Preparing to upgrade my small cluster from Mageia 8/Pg 9 to Mageia 
9/Pg 15. I'm at the point of running pg_upgrade but have received 
anerror message:


You are going to have to be more specific on the Postgres version. 
Prior to Postgres 10 major version changes where two digits. So for 
Postgres 9.X.x that meant 9.0.x --> 9.6.x

Don't have access to that version without re-booting; probably 9.5


select version();

?


Ray.


--
Raymond O'Donnell // Galway // Ireland
r...@rodonnell.ie





Re: Upgrade problem

2023-09-11 Thread Adrian Klaver

On 9/11/23 09:33, Graeme wrote:

On 11/09/2023 17:13, Adrian Klaver wrote:

On 9/11/23 09:04, Graeme wrote:
Preparing to upgrade my small cluster from Mageia 8/Pg 9 to Mageia 
9/Pg 15. I'm at the point of running pg_upgrade but have received 
anerror message:


You are going to have to be more specific on the Postgres version. 
Prior to Postgres 10 major version changes where two digits. So for 
Postgres 9.X.x that meant 9.0.x --> 9.6.x

Don't have access to that version without re-booting; probably 9.5


In psql do:

select version();


Where are you running the pg_upgrade and what version of it are you 
using?



pg_upgrade (PostgreSQL) 15.3

I specified -B /usr/bin


Your  Postgres 15 is on one machine(OS version) and your Postgres 9.X is 
on another machine(OS version), how are reaching the Postgres installs 
on both?






Graeme Gemmill






--
Adrian Klaver
adrian.kla...@aklaver.com





Re: Upgrade problem

2023-09-11 Thread Graeme

On 11/09/2023 17:13, Adrian Klaver wrote:

On 9/11/23 09:04, Graeme wrote:
Preparing to upgrade my small cluster from Mageia 8/Pg 9 to Mageia 
9/Pg 15. I'm at the point of running pg_upgrade but have received 
anerror message:


You are going to have to be more specific on the Postgres version. 
Prior to Postgres 10 major version changes where two digits. So for 
Postgres 9.X.x that meant 9.0.x --> 9.6.x

Don't have access to that version without re-booting; probably 9.5




/mga8/usr/bin/postgres: error while loading shared libraries: 
libssl.so.1.1: cannot open shared object file: No such file or directory

no data was returned by command ""/mga8/usr/bin/postgres" -V"


Where are you running the pg_upgrade and what version of it are you 
using?



pg_upgrade (PostgreSQL) 15.3

I specified -B /usr/bin





However:

[root@bach lib64]# cd /mga8/usr/lib64
[root@bach lib64]# ls -l|grep libssl
-rwxr-xr-x  1 root root  426192 Jul  5 23:07 libssl3.so*
lrwxrwxrwx  1 root root  13 Jun  1 09:35 libssl.so -> 
libssl.so.1.1*

-r-xr-xr-x  1 root root  442424 Feb 27  2021 libssl.so.1.0.0*
-rwxr-xr-x  1 root root  666496 Jun  1 09:36 libssl.so.1.1*

Can someone suggest my next move please?

Ta

Graeme Gemmill




Re: Upgrade problem

2023-09-11 Thread Tom Lane
Graeme  writes:
> Tom, thanks: it's finding other so. files in the correct place

> libpam.so.0 => /lib64/libpam.so.0 (0x7f8d49e1e000)
> libssl.so.1.1 => not found
> libcrypto.so.1.1 => not found
> librt.so.1 => /lib64/librt.so.1 (0x7f8d49e16000)

Note this only shows it looking in /lib64, maybe you need a symlink there?

Alternatively, try ldd on the libssl.so.1.1 file itself, to see if it
has unresolved dependencies.  I'm not totally sure, but I think indirect
unresolved dependencies might display this way.

regards, tom lane




Re: Upgrade problem

2023-09-11 Thread Graeme

On 11/09/2023 17:10, Tom Lane wrote:

Graeme  writes:

Preparing to upgrade my small cluster from Mageia 8/Pg 9 to Mageia 9/Pg
15. I'm at the point of running pg_upgrade but have received anerror
message:
/mga8/usr/bin/postgres: error while loading shared libraries:
libssl.so.1.1: cannot open shared object file: No such file or directory
no data was returned by command ""/mga8/usr/bin/postgres" -V"

You might get useful info from "ldd /mga8/usr/bin/postgres"
about where that executable is looking for libssl.

regards, tom lane


Tom, thanks: it's finding other so. files in the correct place

libpam.so.0 => /lib64/libpam.so.0 (0x7f8d49e1e000)
libssl.so.1.1 => not found
libcrypto.so.1.1 => not found
librt.so.1 => /lib64/librt.so.1 (0x7f8d49e16000)


so there must be another problem.

Graeme


Re: Upgrade problem

2023-09-11 Thread Adrian Klaver

On 9/11/23 09:04, Graeme wrote:
Preparing to upgrade my small cluster from Mageia 8/Pg 9 to Mageia 9/Pg 
15. I'm at the point of running pg_upgrade but have received anerror 
message:


You are going to have to be more specific on the Postgres version. Prior 
to Postgres 10 major version changes where two digits. So for Postgres 
9.X.x that meant 9.0.x --> 9.6.x




/mga8/usr/bin/postgres: error while loading shared libraries: 
libssl.so.1.1: cannot open shared object file: No such file or directory

no data was returned by command ""/mga8/usr/bin/postgres" -V"


Where are you running the pg_upgrade and what version of it are you using?



However:

[root@bach lib64]# cd /mga8/usr/lib64
[root@bach lib64]# ls -l|grep libssl
-rwxr-xr-x  1 root root  426192 Jul  5 23:07 libssl3.so*
lrwxrwxrwx  1 root root  13 Jun  1 09:35 libssl.so -> 
libssl.so.1.1*

-r-xr-xr-x  1 root root  442424 Feb 27  2021 libssl.so.1.0.0*
-rwxr-xr-x  1 root root  666496 Jun  1 09:36 libssl.so.1.1*

Can someone suggest my next move please?

Ta

Graeme Gemmill


--
Adrian Klaver
adrian.kla...@aklaver.com





Re: Upgrade problem

2023-09-11 Thread Tom Lane
Graeme  writes:
> Preparing to upgrade my small cluster from Mageia 8/Pg 9 to Mageia 9/Pg 
> 15. I'm at the point of running pg_upgrade but have received anerror 
> message:

> /mga8/usr/bin/postgres: error while loading shared libraries: 
> libssl.so.1.1: cannot open shared object file: No such file or directory
> no data was returned by command ""/mga8/usr/bin/postgres" -V"

You might get useful info from "ldd /mga8/usr/bin/postgres"
about where that executable is looking for libssl.

regards, tom lane




Upgrade problem

2023-09-11 Thread Graeme
Preparing to upgrade my small cluster from Mageia 8/Pg 9 to Mageia 9/Pg 
15. I'm at the point of running pg_upgrade but have received anerror 
message:


/mga8/usr/bin/postgres: error while loading shared libraries: 
libssl.so.1.1: cannot open shared object file: No such file or directory

no data was returned by command ""/mga8/usr/bin/postgres" -V"

However:

[root@bach lib64]# cd /mga8/usr/lib64
[root@bach lib64]# ls -l|grep libssl
-rwxr-xr-x  1 root root  426192 Jul  5 23:07 libssl3.so*
lrwxrwxrwx  1 root root  13 Jun  1 09:35 libssl.so -> 
libssl.so.1.1*

-r-xr-xr-x  1 root root  442424 Feb 27  2021 libssl.so.1.0.0*
-rwxr-xr-x  1 root root  666496 Jun  1 09:36 libssl.so.1.1*

Can someone suggest my next move please?

Ta

Graeme Gemmill

Re: System (and DB) upgrade problem., "part 2"

2021-01-18 Thread Bruce Momjian
On Mon, Jan 18, 2021 at 03:13:13PM -0600, Ron wrote:
> On 1/18/21 2:58 PM, Bruce Momjian wrote:
> > On Mon, Jan 18, 2021 at 09:53:33PM +0100, W.P. wrote:
> [snip]
> > > Ok, so "step-by-step":
> > > 1), I copy / move "somewhere" OLD DB files (*/pgsql/data/* for -d option),
> > > 2). Do initdb / postgresql-10-setup to create NEW empty base (in
> > > /var/lib/pgsql/ or  somewhere, for -D option),
> > > 3). do pg_upgrade.
> > > 
> > > Is that correct?
> > > 
> > > Is there somewhere "guide for 9.x -> 10.x CONCEPTS changes (and upgrade)
> > > guide"? (clusters etc).
> > The pg_upgade docs have all the steps.
> 
> The documents tend to assume the reader thoroughly knows Postgresql, and
> that's manifestly Not True.

What is your point?  Maybe they shouldn't be using pg_upgrade then,
right?  If the documentaiton is unclear, please explain why.

-- 
  Bruce Momjian  https://momjian.us
  EnterpriseDB https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee





Re: System (and DB) upgrade problem., "part 2"

2021-01-18 Thread David G. Johnston
On Mon, Jan 18, 2021 at 2:13 PM Ron  wrote:

> The documents tend to assume the reader thoroughly knows Postgresql, and
> that's manifestly Not True.
>

Maybe not, but users are still expected to read the documentation.  If
there remains questions or concerns after doing so then by asking such
there is a chance for someone to decide to volunteer an improvement to the
documentation so that the same question doesn't have to be asked in the
future.

David J.


Re: System (and DB) upgrade problem., "part 2"

2021-01-18 Thread Ron

On 1/18/21 2:58 PM, Bruce Momjian wrote:

On Mon, Jan 18, 2021 at 09:53:33PM +0100, W.P. wrote:

[snip]

Ok, so "step-by-step":
1), I copy / move "somewhere" OLD DB files (*/pgsql/data/* for -d option),
2). Do initdb / postgresql-10-setup to create NEW empty base (in
/var/lib/pgsql/ or  somewhere, for -D option),
3). do pg_upgrade.

Is that correct?

Is there somewhere "guide for 9.x -> 10.x CONCEPTS changes (and upgrade)
guide"? (clusters etc).

The pg_upgade docs have all the steps.


The documents tend to assume the reader thoroughly knows Postgresql, and 
that's manifestly Not True.


--
Angular momentum makes the world go 'round.




Re: System (and DB) upgrade problem., "part 2"

2021-01-18 Thread Bruce Momjian
On Mon, Jan 18, 2021 at 09:53:33PM +0100, W.P. wrote:
> W dniu 18.01.2021 o 17:19, Laurenz Albe pisze:
> > On Mon, 2021-01-18 at 05:33 +0100, W.P. wrote:
> > > For 9.5 to 9.6 transition, it worked like charm. (except some problems
> > > with parsing json data in a view, but this I will address later, after
> > > upgrade to final version - Fedora 30, probably PG 10.x).
> > > 
> > > Now I have problem with 9.6 -> 10.7 (Fedora 27 -> 28) upgrade.
> > > As expected after system upgrade, database fails to start "files
> > > incompatible with binaries".
> > > 
> > > Found pg_upgrade, command line options "-b
> > > /usr/lib/pgsql/postgresql-9.6/bin -B /usr/bin -d /var/lib/pgsql/data/"
> > > BUT what should I put for option -D? ("new cluster data") Was
> > > (directory) already created for me (during system upgrade), or have I to
> > > create it somewhere (where? is best practice).
> > > 
> > > There are NO logs for today trial to start in
> > > /var/lib/pgsql/data/pg_log/. Where they could be?
> > You would call "initdb" or "postgresql-10-setup" to create a new, empty
> > cluster in version 10 and use that with -D.
> Ok, so "step-by-step":
> 1), I copy / move "somewhere" OLD DB files (*/pgsql/data/* for -d option),
> 2). Do initdb / postgresql-10-setup to create NEW empty base (in
> /var/lib/pgsql/ or  somewhere, for -D option),
> 3). do pg_upgrade.
> 
> Is that correct?
> 
> Is there somewhere "guide for 9.x -> 10.x CONCEPTS changes (and upgrade)
> guide"? (clusters etc).

The pg_upgade docs have all the steps.

-- 
  Bruce Momjian  https://momjian.us
  EnterpriseDB https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee





Re: System (and DB) upgrade problem., "part 2"

2021-01-18 Thread W.P.

W dniu 18.01.2021 o 17:19, Laurenz Albe pisze:

On Mon, 2021-01-18 at 05:33 +0100, W.P. wrote:

For 9.5 to 9.6 transition, it worked like charm. (except some problems
with parsing json data in a view, but this I will address later, after
upgrade to final version - Fedora 30, probably PG 10.x).

Now I have problem with 9.6 -> 10.7 (Fedora 27 -> 28) upgrade.
As expected after system upgrade, database fails to start "files
incompatible with binaries".

Found pg_upgrade, command line options "-b
/usr/lib/pgsql/postgresql-9.6/bin -B /usr/bin -d /var/lib/pgsql/data/"
BUT what should I put for option -D? ("new cluster data") Was
(directory) already created for me (during system upgrade), or have I to
create it somewhere (where? is best practice).

There are NO logs for today trial to start in
/var/lib/pgsql/data/pg_log/. Where they could be?

You would call "initdb" or "postgresql-10-setup" to create a new, empty
cluster in version 10 and use that with -D.

Ok, so "step-by-step":
1), I copy / move "somewhere" OLD DB files (*/pgsql/data/* for -d option),
2). Do initdb / postgresql-10-setup to create NEW empty base (in 
/var/lib/pgsql/ or  somewhere, for -D option),

3). do pg_upgrade.

Is that correct?

Is there somewhere "guide for 9.x -> 10.x CONCEPTS changes (and upgrade) 
guide"? (clusters etc).


Laurent

Yours,
Laurenz Albe







Re: System (and DB) upgrade problem., "part 2"

2021-01-18 Thread Laurenz Albe
On Mon, 2021-01-18 at 05:33 +0100, W.P. wrote:
> For 9.5 to 9.6 transition, it worked like charm. (except some problems 
> with parsing json data in a view, but this I will address later, after 
> upgrade to final version - Fedora 30, probably PG 10.x).
> 
> Now I have problem with 9.6 -> 10.7 (Fedora 27 -> 28) upgrade.
> As expected after system upgrade, database fails to start "files 
> incompatible with binaries".
> 
> Found pg_upgrade, command line options "-b 
> /usr/lib/pgsql/postgresql-9.6/bin -B /usr/bin -d /var/lib/pgsql/data/" 
> BUT what should I put for option -D? ("new cluster data") Was 
> (directory) already created for me (during system upgrade), or have I to 
> create it somewhere (where? is best practice).
> 
> There are NO logs for today trial to start in 
> /var/lib/pgsql/data/pg_log/. Where they could be?

You would call "initdb" or "postgresql-10-setup" to create a new, empty
cluster in version 10 and use that with -D.

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com





Re: System (and DB) upgrade problem., "part 2"

2021-01-18 Thread Peter J. Holzer
On 2021-01-18 05:33:05 +0100, W.P. wrote:
> Now I have problem with 9.6 -> 10.7 (Fedora 27 -> 28) upgrade.
> As expected after system upgrade, database fails to start "files
> incompatible with binaries".
> 
> Found pg_upgrade, command line options "-b /usr/lib/pgsql/postgresql-9.6/bin
> -B /usr/bin -d /var/lib/pgsql/data/" BUT what should I put for option -D?
> ("new cluster data") Was (directory) already created for me (during system
> upgrade), or have I to create it somewhere (where? is best practice).

The Debian/Ubuntu package contains a script pg_upgradecluster which
knows about the distribution-specific directory layout. You would
normally use that script instead pg_upgrade directly.

Maybe the Fedora package has something similar?

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature


Re: System (and DB) upgrade problem., "part 2"

2021-01-17 Thread W.P.

W dniu 13.01.2021 o 12:28, Laurenz Albe pisze:

On Wed, 2021-01-13 at 07:41 +0100, W.P. wrote:

I am upgrading Fedora 24 to (now) 26, PostgreSQL stopped starting (as
expected), the message from systemctl was to do "postgresql-setup
--upgrade".

Did installed the tool, loaunched.

But it fails with (attached logs) messages, I am missing some libraries,
what should I install?

The logs complain about missing the "dblink" library, so you forgot to install
the -contrib package.

Remember to REINDEX all indexes on string columns, because the collations
may have changed.

Yours,
Laurenz Albe
For 9.5 to 9.6 transition, it worked like charm. (except some problems 
with parsing json data in a view, but this I will address later, after 
upgrade to final version - Fedora 30, probably PG 10.x).


Now I have problem with 9.6 -> 10.7 (Fedora 27 -> 28) upgrade.
As expected after system upgrade, database fails to start "files 
incompatible with binaries".


Found pg_upgrade, command line options "-b 
/usr/lib/pgsql/postgresql-9.6/bin -B /usr/bin -d /var/lib/pgsql/data/" 
BUT what should I put for option -D? ("new cluster data") Was 
(directory) already created for me (during system upgrade), or have I to 
create it somewhere (where? is best practice).


There are NO logs for today trial to start in 
/var/lib/pgsql/data/pg_log/. Where they could be?


Laurent






Re: System (and DB) upgrade problem.

2021-01-13 Thread Laurenz Albe
On Wed, 2021-01-13 at 07:41 +0100, W.P. wrote:
> I am upgrading Fedora 24 to (now) 26, PostgreSQL stopped starting (as 
> expected), the message from systemctl was to do "postgresql-setup 
> --upgrade".
> 
> Did installed the tool, loaunched.
> 
> But it fails with (attached logs) messages, I am missing some libraries, 
> what should I install?

The logs complain about missing the "dblink" library, so you forgot to install
the -contrib package.

Remember to REINDEX all indexes on string columns, because the collations
may have changed.

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com





System (and DB) upgrade problem.

2021-01-12 Thread W.P.

Hi there,

I am upgrading Fedora 24 to (now) 26, PostgreSQL stopped starting (as 
expected), the message from systemctl was to do "postgresql-setup 
--upgrade".


Did installed the tool, loaunched.

But it fails with (attached logs) messages, I am missing some libraries, 
what should I install?



Laurent.

could not load library "$libdir/dblink":
BŁĄD:  nie można uzyskać dostępu do pliku "$libdir/dblink": Nie ma takiego 
pliku ani katalogu

could not load library "$libdir/adminpack":
BŁĄD:  nie można uzyskać dostępu do pliku "$libdir/adminpack": Nie ma takiego 
pliku ani katalogu

Performing Consistency Checks
-
Checking cluster versions   ok
Checking database user is the install user  ok
Checking database connection settings   ok
Checking for prepared transactions  ok
Checking for reg* system OID user data typesok
Checking for contrib/isn with bigint-passing mismatch   ok
Checking for roles starting with 'pg_'  ok
Creating dump of global objects ok
Creating dump of database schemas
  arrdb
  asterisk
  jip
  laurent
  orthanc
  pacsdb
  postgres
  scadadb
  template1
ok
Checking for presence of required libraries fatal

Your installation references loadable libraries that are missing from the
new installation.  You can add these libraries to the new installation,
or remove the functions using them from the old installation.  A list of
problem libraries is in the file:
loadable_libraries.txt

Failure, exiting