Обсуждение: [pgsql-pkg-debian] problem with pg_upgradecluster from postgresql 8.1 to 9.1

Hello,
I know this is a quite old system, but I hope someone will give some
hint on how to find the problem.

I am trying to upgrade an old 8.1 cluster to 9.1 on an ubuntu dapper
system. 9.1 is the latest installable form PGDG on that old dapper, in
fact packages have been installed without problems.

When running pg_upgradecluster, the procedure stop just after new
cluster creation. No errors are available on the logs: the new cluster
seems working, but the upgrade stop and write "Could not start target
cluster".

Here are all details

1. the original system have two clusters. Only one is being upgraded:

root@atf-810:/var/lib/postgresql/8.1# pg_lsclusters 
Version Cluster   Port Status Owner    Data directory                     Log file
8.1     main      5432 online postgres /var/lib/postgresql/8.1/main       /var/log/postgresql/postgresql-8.1-main.log
8.1     q3        5433 online postgres /var/lib/postgresql/8.1/q3         /var/log/postgresql/postgresql-8.1-q3.log

2. this is the procedure that fails

root@atf-810:/var/lib/postgresql/8.1# pg_upgradecluster 8.1 main
Stopping old cluster...
Disabling connections to the old cluster during upgrade...
Restarting old cluster with restricted connections...
Creating new cluster (configuration: /etc/postgresql/9.1/main, data: /var/lib/postgresql/9.1/main)...
Moving configuration file /var/lib/postgresql/9.1/main/postgresql.conf to /etc/postgresql/9.1/main...
Moving configuration file /var/lib/postgresql/9.1/main/pg_hba.conf to /etc/postgresql/9.1/main...
Moving configuration file /var/lib/postgresql/9.1/main/pg_ident.conf to /etc/postgresql/9.1/main...
Configuring postgresql.conf to use port 5434...
Disabling connections to the new cluster during upgrade...
The PostgreSQL server failed to start. Please check the log output:
2017-08-17 14:05:18 CEST LOG:  database system was shut down at 2017-08-17 14:05:17 CEST
2017-08-17 14:05:18 CEST LOG:  autovacuum launcher started
2017-08-17 14:05:18 CEST LOG:  database system is ready to accept connections
2017-08-17 14:05:18 CEST LOG:  incomplete startup packet
Error: Could not start target cluster

3. the new cluster is correctly running

root@atf-810:/var/lib/postgresql/8.1# pg_lsclusters
Version Cluster   Port Status Owner    Data directory                     Log file
8.1     main      5432 online postgres /var/lib/postgresql/8.1/main       /var/log/postgresql/postgresql-8.1-main.log
8.1     q3        5433 online postgres /var/lib/postgresql/8.1/q3         /var/log/postgresql/postgresql-8.1-q3.log
9.1     main      5434 online postgres /var/lib/postgresql/9.1/main       /var/log/postgresql/postgresql-9.1-main.log

4. the log of new cluster is exactly what alredy printed by
pg_upgradecluster. The last lines of old cluster log are:

oot@atf-810:/var/lib/postgresql/8.1# tail -20 /var/log/postgresql/postgresql-8.1-main.log
LOG:  incomplete startup packet
LOG:  autovacuum: processing database "postgres"
LOG:  incomplete startup packet
LOG:  incomplete startup packet
LOG:  received smart shutdown request
LOG:  shutting down
LOG:  database system is shut down
LOG:  could not load root certificate file "root.crt": No SSL error reported
DETAIL:  Will not verify client certificates.
LOG:  database system was shut down at 2017-08-17 14:05:10 CEST
LOG:  checkpoint record is at A8/30BC8A4
LOG:  redo record is at A8/30BC8A4; undo record is at 0/0; shutdown TRUE
LOG:  next transaction ID: 3262147080; next OID: 206065
LOG:  next MultiXactId: 3; next MultiXactOffset: 5
LOG:  database system is ready
LOG:  incomplete startup packet
LOG:  transaction ID wrap limit is 299003, limited by database "postgres"
LOG:  autovacuum: processing database "postgres"
LOG:  incomplete startup packet
LOG:  autovacuum: processing database "template1"

5. this is the version of postgresql-common, that includes
pg_upgradecluster command:

root@atf-810:/var/lib/postgresql/8.1# apt-cache policy postgresql-common
postgresql-common:
  Installed: 137.pgdg50+1~1353587801.bzr1228.24
  Candidate: 137.pgdg50+1~1353587801.bzr1228.24
  Version table:
 *** 137.pgdg50+1~1353587801.bzr1228.24 0
        500 http://apt.postgresql.org lenny-pgdg/main Packages
        100 /var/lib/dpkg/status
     53ubuntu3 0
        500 http://old-releases.ubuntu.com dapper/main Packages

Thank you,
Giuseppe

Re: Giuseppe Sacco 2017-08-17 <1502973744.23289.7.camel@eppesuigoccas.homedns.org>
> Hello,
> I know this is a quite old system, but I hope someone will give some
> hint on how to find the problem.
>
> I am trying to upgrade an old 8.1 cluster to 9.1 on an ubuntu dapper
> system. 9.1 is the latest installable form PGDG on that old dapper, in
> fact packages have been installed without problems.
>
> When running pg_upgradecluster, the procedure stop just after new
> cluster creation. No errors are available on the logs: the new cluster
> seems working, but the upgrade stop and write "Could not start target
> cluster".

Hi,

I can't say what the problem is - what's puzzling me is that usually
pg_upgradecluster should drop the new cluster if there are any
problems during the upgrade, but the 9.1/main cluster seems to be
running just fine for you after the upgrade attempt.

To move forward, I'd just manually do

pg_dumpall -p 5432 | psql -p 5434

That will transfer the 8.1/main contents to 9.1/main.


It's been a long time, but off-hand, I'm not aware of any specific
bugs that would explain the behavior you are seeing. Alternatively,
you could try installing a recent postgresql-common version, it should
still support 8.1.

Christoph

Hello Christoph,
I tried to follow your suggestion as described here:

Il giorno sab, 19/08/2017 alle 10.32 +0200, Christoph Berg ha
scritto:[...]
> I can't say what the problem is - what's puzzling me is that usually
> pg_upgradecluster should drop the new cluster if there are any
> problems during the upgrade, but the 9.1/main cluster seems to be
> running just fine for you after the upgrade attempt.
>
> To move forward, I'd just manually do
>
> pg_dumpall -p 5432 | psql -p 5434

and, indeed, the cluster copy started. Unfortunately this ended up in a
disk full. This is quite strange since the old cluster disk usage is
about 68Gb, while the new cluster arrived to 119Gb and filled the file
system.

I might enlarge the file system and try again, but 119Gb against 68Gb
sounds strange to me. I'll try to start again the complete operation
and save psql output and postgresql log. (Now I already dropped 9.1
cluster and even its logs were deleted.)

Bye,
Giuseppe