Re: Aide sur pg_upgrade : il ne lance pas le nouveau postmaster

On Thu, 2014-02-13 at 23:15 +0100, Sebastien Douche wrote:
> On Thu, Feb 13, 2014 at 10:52 PM, Guillaume Lelarge
> <guillaume(at)lelarge(dot)info> wrote:
> > Les deux serveurs doivent être arrêtés au lancement de pg_upgrade.
>
> Ce qui est le cas.
>
> > Ce serait plus simple de t'aider avec les fichiers de traces complets.
>
> J'ai copié tout le contenu...
>
> postgres(at)SPV:/tmp$ /opt/nova/current/nova/parts/pg93/bin/pg_upgrade -b
> /usr/lib/postgresql/8.4/bin -B /opt/nova/current/nova/parts/pg93/bin
> -d /srv/postgresql/8.4/main/ -D /srv/postgresql/9.3/main
> Performing Consistency Checks
> -----------------------------
> Checking cluster versions ok
> Checking database user is a superuser ok
> Checking for prepared transactions ok
> Checking for reg* system OID user data types ok
> Checking for contrib/isn with bigint-passing mismatch ok
> Checking for large objects ok
> Creating dump of global objects
> *failure*
>
> Consult the last few lines of "pg_upgrade_utility.log" for
> the probable cause of the failure.
> Failure, exiting
> postgres(at)SPV:/tmp$ ls
> pg_upgrade_internal.log pg_upgrade_server.log
> pg_upgrade_utility.log upgrade_successful
>
> postgres(at)SPV:/tmp$ cat pg_upgrade_internal.log
>
> -----------------------------------------------------------------
> pg_upgrade run on Thu Feb 13 23:13:54 2014
> -----------------------------------------------------------------
>
> Performing Consistency Checks
> -----------------------------
> Checking cluster versions ok
> Checking database user is a superuser ok
> Checking for prepared transactions ok
> Checking for reg* system OID user data types ok
> Checking for contrib/isn with bigint-passing mismatch ok
> Checking for large objects ok
> Creating dump of global objects
> *failure*
> Consult the last few lines of "pg_upgrade_utility.log" for
> the probable cause of the failure.
> postgres(at)SPV:/tmp$ cat pg_upgrade_server.log
>
> -----------------------------------------------------------------
> pg_upgrade run on Thu Feb 13 23:13:54 2014
> -----------------------------------------------------------------
>
> command: "/usr/lib/postgresql/8.4/bin/pg_ctl" -w -l
> "pg_upgrade_server.log" -D "/srv/postgresql/8.4/main/" -o "-p 50432 -c
> autovacuum=off -c autovacuum_freeze_max_age=2000000000 -c
> listen_addresses='' -c unix_socket_permissions=0700" start >>
> "pg_upgrade_server.log" 2>&1
> waiting for server to start.... done
> server started
>
>
> command: "/usr/lib/postgresql/8.4/bin/pg_ctl" -w -D
> "/srv/postgresql/8.4/main/" -o "" -m fast stop >>
> "pg_upgrade_server.log" 2>&1
> waiting for server to shut down.... done
> server stopped
>
>
> postgres(at)SPV:/tmp$ cat pg_upgrade_utility.log
>
> -----------------------------------------------------------------
> pg_upgrade run on Thu Feb 13 23:13:54 2014
> -----------------------------------------------------------------
>
> command: "/opt/nova/current/nova/parts/pg93/bin/pg_dumpall" --port
> 50432 --username "postgres" --schema-only --globals-only
> --quote-all-identifiers --binary-upgrade -f
> pg_upgrade_dump_globals.sql >> "pg_upgrade_utility.log" 2>&1
> pg_dumpall: could not connect to database "template1": could not
> connect to server: No such file or directory
> Is the server running locally and accepting
> connections on Unix domain socket "/tmp/.s.PGSQL.50432"?
>
>
>

OK. En fait, le pg_dumpall 9.3 essaie de se connecter au serveur 8.4. Ce
dernier démarre apparemment. Par contre, pg_dumpall cherche la socket
dans /tmp. Serait-il possible que la 8.4 place sa socket ailleurs ? (ça
arrive sur Debian par exemple)

Si tu démarres la 8.4 manuellement, que vaut unix_socket_directory ?

Autre possibilité, ajoute l'option -o "unix_socket_directory=/tmp" à
pg_upgrade.

--
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)