Forums PostgreSQL.fr

Alain V.

Membre

La colonne « reltriggers » n'existe pas

Bonjour le forum.

Mon niveau est juste "basique" avec Postgres et tout est dans le titre.

Comme je viens de créer une nouvelle base de données, avant de la remplir, je commence par mettre en place sa sauvegarde ;-)
Je découvre immédiatement ceci :

$ pg_dump -i -D -h 192.168.1.4 -U archimede archimede > dump.sql
Mot de passe :

pg_dump: version du serveur : 8.4.5 ; pg_dump version : 8.3.13
pg_dump: traitement malgré la différence des versions
pg_dump: la commande SQL a échoué
pg_dump: Message d'erreur du serveur : ERREUR:  la colonne « reltriggers » n'existe pas
LINE 1: ...oles WHERE oid = relowner) as rolname, relchecks, reltrigger...
                                                             ^
pg_dump: La commande était : SELECT c.tableoid, c.oid, relname, relacl, relkind, relnamespace, (SELECT rolname FROM pg_catalog.pg_roles WHERE oid = relowner) as rolname, 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' and 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 by c.oid

Le client est en 8.3 sur une Lenny. Il parle avec :
- un serveur en 8.3 sur une Lenny
- un serveur en 8.4 sur une Squeeze. D'où le "-i" du pg_dump ci-dessus.

Le serveur 8.4, n'est pas sur le même brin de réseau que le client.
Le client peut s'y connecter sans problème.

En cherchant profondément dans ce fil :
http://listes.postgresql.fr/pipermail/t … 00490.html
je crois comprendre qu'il s'agit d'un problème de compatibilité entre les versions  avec Slonik.

...
-<li>Change default $LOGDIR, so that distros won't need to patch it.
+  <li> pg_class.reltriggers n'existe plus dans 8.4 et donc ne doit plus être touché
...

Si Slonik a été installé, cela a dû être fait automatiquement avec les autres paquets lors de l'aptitude instal...

Il me semble comprendre que les "ubuntéros" avaient réglé un bug :
http://www.mail-archive.com/universe-bu … 61330.html
Est-ce que ça concerne aussi mon cas sous Debian?

J'ai trouvé une autre situation similaire ici:
http://forums.postgresql.fr/viewtopic.php?id=742
Par contre, contrairement à ce dernier cas, moi, je n'ai pas touché aux tables systèmes. Vu mon niveau, je ne m'y aventure pas.
Comme je viens juste d'installer Postgres sur cette nouvelle machine je n'ai fait que de créer/droper des utilisateurs et des bases sous Postgres, des bases, des tables et des vues sous des utilisateurs différents.

Voici la base qui refuse de se laisser dumper :

$ psql -h 192.168.1.4 -U archimede archimede
Mot de passe :
Bienvenue dans psql 8.3.13 (serveur 8.4.5), l'interface interactive de PostgreSQL.

Saisissez:
    \copyright pour les termes de distribution
    \h pour l'aide-mémoire des commandes SQL
    \? pour l'aide-mémoire des commandes psql
    \g ou point-virgule en fin d'instruction pour exécuter la requête
    \q pour quitter

ATTENTION : vous êtes connecté sur un serveur dont la version majeure est
8.4 alors que votre client psql est en version majeure 8.3. Certaines
commandes avec antislashs, comme \d, peuvent ne pas fonctionner
correctement.

Connexion SSL (chiffrement : DHE-RSA-AES256-SHA, bits : 256)

archimede=> \d
                 Liste des relations
 Schéma |        Nom        |   Type   | Propriétaire
--------+-------------------+----------+--------------
 public | table1            | table    | archimede
 public | table1_champ1_seq | séquence | archimede
 public | view1             | vue      | archimede
 public | view2             | vue      | archimede
(4 lignes)

archimede=> SELECT * FROM table1;
 champ1 | champ2
--------+---------
      1 | Ligne1
      2 | Ligne2
      3 | Ligne3
      4 | Ligne4
      5 | Ligne5
      6 | Ligne6
      7 | Ligne7
      8 | Ligne8
      9 | Ligne9
     10 | Ligne10
(10 lignes)

archimede=> \d table1
ERREUR:  la colonne « reltriggers » n'existe pas
LINE 1: SELECT relhasindex, relkind, relchecks, reltriggers, relhasr...

J'avais créé la table ainsi :

CREATE TABLE table1 (champ1 serial, champ2 varchar(30));

Je pourrais mettre ça sur le dos du "\d" qui pourrait ne pas fonctionner correctement mais cela ne tient pas pour pg_dump.

Bref, je fais du ping pong entre un message relatif à reltriggers et celui d'un serveur qui n'accepte que difficilement une compatibilité descendante avec un client.

Est-ce que quelqu'un aurait une idée dans quelles directions devrais-je plutot orienter mes recherches?

Merci par avance.

Alain V.

Membre

Re : La colonne « reltriggers » n'existe pas

Si le dump est exécuté localement par l'utilisateur sur sa base alors il n'y a aucun message d'erreur.

$ pg_dump > dump.sql
Mot de passe :
$

gleu

Administrateur

Re : La colonne « reltriggers » n'existe pas

Vous utilisez une version de pg_dump prévue pour un serveur 8.3 avec un serveur 8.4. pg_dump fait un tas de requêtes sur les tables systèmes et notamment il essaie de récupérer une information d'une colonne reltriggers qui existait en 8.3 mais qui n'existe plus en 8.4.

Autrement dit, n'utilisez pas un pg_dump de 8.3 pour sauvegarder un serveur en 8.4. Et du coup, utilisez un pg_dump 8.4.

---

Guillaume.

Alain V.

Membre

Re : La colonne « reltriggers » n'existe pas

Merci beaucoup pour votre réponse.

Comme je ne souhaite pas utiliser les backports, cela implique que je doit aligner toutes mes Debian qui communiquent avec Postgres.

gleu

Administrateur

Re : La colonne « reltriggers » n'existe pas

Ou compiler PostgreSQL.

---

Guillaume.