Ce n'est pas suffisant! Je vois avec le moniteur de perf que c'est une session postgresql, mais je voudrais avoir également le process ID..

Je m'en suis sortie en ne faisant un export que du schéma à récupérer en mode plain, et j'ai récupéré sur mon serveur de destination en postgresql 8.2 par la commande suivante :
psql.exe -f "mon-fichier-export-en-mode-plain-postgre9.sql" -p <port> -h localhost <labase-destination> <le-user>

Merci à tous.
Chrystèle.

Bonjour et merci pour vos réponses. Pour info, je suis sur Windows.

J'ai effectivement essayé depuis le serveur en Version 8 de faire un pg_dump avec l'option -i mais ça ne fonctionne pas.
pg_dump.exe -i -h serveuren9 -p 5432 -U postgres  -f fichier.backup <nomdelabase>

pg_dump: server version: 9.0.3; pg_dump version: 8.2.11
pg_dump: proceeding despite version mismatch
pg_dump: SQL command failed
pg_dump: Error message from server: ERREUR:  la colonne ┬½ reltriggers ┬╗ n'exis
te pas
LINE 1: ...oles WHERE oid = relowner) as rolname, relchecks, reltrigger...
                                                             ^
pg_dump: The command was: SELECT c.tableoid, c.oid, relname, relacl, relkind, re
lnamespace, (SELECT rolname FROM pg_catalog.pg_roles WHERE oid = relowner) as ro
lname, relchecks, reltriggers, relhasindex, relhasrules, relhasoids, d.refobjid
as owning_tab, d.refobjsubid as owning_col, (SELECT spcname FROM pg_tablespace t
WHERE t.oid = c.reltablespace) AS reltablespace, array_to_string(c.reloptions,
', ') as reloptions from pg_class c left join pg_depend d on (c.relkind = 'S' an
d d.classid = c.tableoid and d.objid = c.oid and d.objsubid = 0 and d.refclassid
= c.tableoid and d.deptype = 'a') where relkind in ('r', 'S', 'v', 'c') order b
y c.oid

Merci pour votre retour. J'ai procédé par un pgdump_all pour l'extraction et psql pour l'import.
Par contre je ne peux pas consulter les bases en Posgresql 9 depuis un pgadmin 1.4.2, j'ai les messages d'erreurs suivant :

"la colonne "datconfig" n'existe pas au caractère 48..."
"column not found in pgsetbase:rolconfig...."

C'est bon, ne cherchez plus, j'ai trouvé :

solution : j'ai enlevé du compte postgres le groupe "administrateur"

Merci pour l'info, je vais essayé comme tu dis. J'ai essayé de réexécuré l'installeur, et effectivement, ça marche pô très très bien!

L'inconvénient d'avoir toutes les bases sur un même serveur est le suivant :

En cas de restauration physique avec application des logs archivés (base en mode WAL) , si toutes les bases sont sur une même serveur, et que l'on doit restaurer une base à un instant donné (c'est à dire repartir du dernier backup avec application des logs archivés), toutes les bases seront impactées, c'est à dire que toutes les bases reviendront à l'état correspondant à un instant t.
S'il y a par exemple un suppression malencontreuse sur une base donnée "BASE1" il y a une heure, on ne pourra pas ne restaurer que la base "BASE1" à l'état avant l'erreur, mais toutes les bases reviendront à l'état où elles étaient à l'heure spécifié lors de la restauration.

D'autre part, j'ai essayer d'installer 2 fois le moteurs PostGreSQL sur un même serveur, mais ça plante. Je suis partie d'une installation à partir d'un ficheir .msi, peut-être est-ce la raison...