Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
je rencontre un probleme avec pg_upgrade que je ne parviens pas à corriger malgré mes nombreuses recherches sur Google.
Lorsque je lance la commande pg_upgrade avec les bons parametres voici ce qui se passe :
cmd : /usr/lib/postgresql/9.1/bin/pg_upgrade -u postgres -d 8.4/main/ -D 9.1/main/ -b /usr/lib/postgresql/8.4/bin/ -B /usr/lib/postgresql/9.1/bin/ -p 5432 -P 5434
dump :
Performing Consistency Checks
-----------------------------
Checking current, bin, and data directories ok
Checking cluster versions ok
connection to database failed: FATAL: ne peut pas accéder aux tables temporaires d'autres sessions
unable to connect to old postmaster started with the command: "/usr/lib/postgresql/8.4/bin/pg_ctl" -w -l "/dev/null" -D "/var/lib/postgresql/8.4/main" -o "-p 5432 -c autovacuum=off -c autovacuum_freeze_max_age=2000000000" start >> "/dev/null" 2>&1
Failure, exiting
A priori lorsqu'il essaye de démarrer l'ancien postmaster, il ne parvient pas à accéder aux bonnes tables temporaires, ca génère une erreur et derrière tout s'arrete.
Une idée ?
Hors ligne
info peut etre utile :
je parviens à reproduire l'erreur en tentant de me connecter à template1 sur mon pg version 8.4 (psql template1 -p5432)
alors que je me connecte sans probleme sur mon pg version 9.1 (psql template1 -p5434)
Je ne suis pas à l'aise avec ce "template1" mais je suis tenté de dire que j'aurais un soucis de paramétrage sur ma bdd actuelle (8.4) ?
Hors ligne
Bonjour.
A tout hasard, peut-être un problème d'autorisation sur certains sous répertoires de la 8.4 ? Je commencerais par regarder celui spécifié par le paramètre de configuration stats_temp_directory (pg_stat_tmp par défaut).
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour, le parametre stats_temp_directory était bien le param par défaut (cad pg_stat_tmp)
Pour etre bien sur, j'ai décommenté la ligne dans postgresql.conf mais ce n'est toujours pas bon.
Savez vous si pg_upgrade travaille sur template1, ce qui pourrait etre la cause de ce bug ? Car pour ma base "normale" je n'ai pas d'erreur du tout et j'accede à tous les objets normalement.
Une solution pourrait etre de regénéré un template1 à partir du template0 ?
Je n'ai pourtant pas souvenir d'avoir "joué" avec template1
Hors ligne
Oui, on peut tout à fait re-cloner template1 à partir de template0, ça ne pose pas de pb. Mais c'est vrai que l'erreur est bizarre. Surtout que dans template1 il n'est pas censé y avoir de tables temporaire.
D'un autre côté, je ne comprends pas l'importance de la base template1 par rapport à une autre: pg_upgrade travaille sur tout le cluster de toutes façons…
Marc.
Hors ligne
Je parle de template1 car j'ai le meme mesage d'erreur quand j'essaye de m'y connecter que quand je lance la procédure pg_upgrade. D'où mon interrogation vis à vis de template1
Cependant, il est vrai que je ne vois pas vraiment le rapport entre pg_upgrade et template1.
Aujourdhui mon cluster 8.4 contient 2 bases user et les 2 bases systeme (template0 et template1). Recemment nous avons créé une base sans aucun probleme.
A noter que sur pgadmin, quand j'affiche les objets systeme, je prends toujours cette meme erreur quand j'essaye d'accéder à template1 de mon pg 8.4.
Alors que sur mon pg 9.1, j'accede normalement à tous les objets de cette base.
N'étant pas une base de données de production (et ne sachant pas quoi faire 
), je vais essayer de recloner template1 a partir de template0. Je vous tiens au courant.
Hors ligne
En regénérant template1 à partir de template0, pg_upgrade se lance normalement ! Victory is mine 
Merci pour votre aide et votre réactivité
Hors ligne
Pages : 1
