Le portail francophone de la géomatique

Nicolas Granier · Thu 27 February 2014 17:16

Bonjour à tous,
Je me trouve devant une énigme.
J'ai rajouté récemment une table dans ma base de données POSTGRESQL. Je fais régulièrement un dump de ma base de données et aujourd'hui j'ai un bug lors du test de restauration.
L'erreur me dit que la séquence de ma nouvelle table n'existe pas.

Après lecture du dump en SQL, je me rends compte que l'export de cette nouvelle table est différente des précédentes. Je m'explique :
AVANT

Code:

CREATE TABLE anciennetable (
    identifiant bigint NOT NULL )
  
CREATE SEQUENCE anciennetable_identifiant_seq
    START WITH 1
    INCREMENT BY 1
    NO MINVALUE
    NO MAXVALUE
    CACHE 1;



ALTER SEQUENCE anciennetable_identifiant_seq OWNED BY anciennetable.identifiant;

MAINTENANT

Code:

CREATE TABLE nouvelletable (
    identifiant DEFAULT nextval('nouvelletable_identifiant_seq'::regclass) NOT NULL )

Je n'ai plus la création de la séquence ! et j'ai une erreur bien entendu lors de la restauration.
J'ai contourné le problème en forçant dans mon dump l'export de la séquence recalcitrante en passant en paramètre --table nouvelletable_identifiant_seq , mais j'aimerai comprendre ce disfonctionnement.

Nicolas GRANIER

Yves · Fri 28 February 2014 11:51

Bonjour,

Par hasard : est ce que la table a été déplacée dans un autre schéma que celui dans lequel il a été créé ? Est ce qu'il y a un filtre des schémas lors de l'export/import ?

Y a t'il eut un changement de version de la base ? Je ne suis pas sur que cela a un impact. mais au cas où ...

Y.

Nicolas Granier · Fri 28 February 2014 14:29

Bonjour Yves,
Voici quelques précisions :
- pas de déplacement de la table
- pas de filtre dans les schémas, seules les tables sont exportées préfixées par le nom du schéma
- pas non plus de changement de version

par contre j'ai identifié un point de divergence. Tous les autres tables ont été créées en ajoutant le champ identifiant de cette façon

Code:

CREATE TABLE anciennetable ( identifiant bigint SERIAL )

et la dernière qui pose problème a été créée comme ceci

Code:

CREATE TABLE nouvelletable (   identifiant DEFAULT nextval('nouvelletable_identifiant_seq'::regclass)

.

La "méthode" en passant par un SERIAL est bien meilleure, mais j'aimerai comprendre où est le lien (dans pg_catalog surement) entre la table et ma séquence pour identifier des liens rompus ou autres

Nicolas GRANIER

Yves · Fri 28 February 2014 18:01

Bonjour,

SERIAL est une sorte d'alias qui entraîne la création de la séquence, son utilisation comme valeur par défaut sur un champ de type int8.

La deuxième méthode doit planter car s'il ne créé par la séquence (si elle n'est pas déjà créée en fait) sa référence est impossible. Reste à savoir pourquoi la séquence n'est pas créée (exportée).

Une séquence est un objet au même titre qu'une table, un index. Tu peux d'ailleurs faire SELECT * FROM nouvelletable_identifiant_seq. Elle est stockées dans le schéma public par défaut ou celui qui est précisé.

Pour connaître les liens "rompus" tu dois avoir une table interne qui liste les colonnes pour chaque tables, ainsi que les valeurs par défaut. Tu dois pouvoir récupérer la valeur par défaut et donc la séquence, puis chercher si la séquence existe dans la table qui liste les relations :

Code:

SELECT * FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='layer';

Y.

Nicolas Granier · Mon 03 March 2014 12:24

Bonjour Yves,

Une séquence est un objet au même titre qu'une table, un index. Tu peux d'ailleurs faire SELECT * FROM nouvelletable_identifiant_seq. Elle est stockées dans le schéma public par défaut ou celui qui est précisé.

Oui effectivement, je visualise ma base de données avec pg_admin et je vois bien que ma séquence existe. Ce n'est vraiment que l'export qui pose problème.
J'ai visualisé plusieurs informations dans la table information_schema (je l'avais oublié celle-là), et en comparant avec une autre table/sequence créée avec la "méthode SERIAL" je ne constate aucune différence !
De même pg_admin me permet d'afficher les dépendances et toujours aucunes différences.
Soit j'ai l'erreur devant les yeux et je suis myope , soit j'en viens à croire que c'est une information perdue au fin fond de Postgresql que je ne trouverais jamais....

Fritsch · Fri 07 March 2014 20:33

Tous les exemples que tu nous donnes sont des exemples sortis du dump, non ?
A quoi ressemblent-ils si on les regarde dans pgadmin ? Est-ce qu'on voit une différence entre la nouvelle table et les anciennes ?

Et puis : qu'as-tu pris comme options des commandes de dump et de restore ?

Et enfin : dans le fichier de dump, n'y a-t-il rien de changé dans l'entête par rapport au temps où tu n'avais pas la nouvelle table ?

Nicolas Ribot · Sat 08 March 2014 11:39

Bonjour,

Effectivement, si l'option de dump précise d'exporter des tables uniquement (pg_dump - t table1, -t table2 ...), alors il faut préciser aussi les sequences utilisées par les tables:

Code:

pg_dump -t nouvelletable_identifiant_seq -t nouvelletable mabase

Nicolas

Nicolas Granier · Mon 10 March 2014 08:43

Bonjour, merci pour vos retours.

Tous les exemples que tu nous donnes sont des exemples sortis du dump, non ?

Oui effectivement

A quoi ressemblent-ils si on les regarde dans pgadmin ? Est-ce qu'on voit une différence entre la nouvelle table et les anciennes ?

Dans PGAdmin, c'est exactement la même chose

qu'as-tu pris comme options des commandes de dump et de restore ?

les options sont celles-ci : --no-password --format plain --no-owner --create --encoding UTF8 --no-privileges --verbose

Et enfin : dans le fichier de dump, n'y a-t-il rien de changé dans l'entête par rapport au temps où tu n'avais pas la nouvelle table ?

J'ai conservé des historiques des versions d'export et rien n'a changé entres les anciens et les nouveaux dump.

Nicolas, tu précises que

si l'option de dump précise d'exporter des tables uniquement (pg_dump - t table1, -t table2 ...), alors il faut préciser aussi les séquences utilisées par les tables

mais je ne le faisais pas avant et ça marchait très bien.
Pour toutes les tables créées avec un identifiant de type "serial", les séquences étaient implicitement exportées dans le dump. C'est juste pour la table que j'ai créée de cette manière que ça ne marche pas

Code:

CREATE TABLE nouvelletable (   identifiant DEFAULT nextval('nouvelletable_identifiant_seq'::regclass)

Dernière modification par Nicolas Granier (Mon 10 March 2014 08:44)

Nicolas Ribot · Mon 10 March 2014 10:43

Bonjour,

Oui, pardon, j'ai lu un peu vite votre message: vous y précisez que l'export avec -t marche.

Quelle est la commande exacte de creation de la table qui pose probleme ? Dans la commande:

Code:

CREATE TABLE nouvelletable (   identifiant DEFAULT nextval('nouvelletable_identifiant_seq'::regclass)

Il manque le type de la colonne identifiant.

• Si le dump ne contient aucune référence à la sequence, ca sent la corruption de la base, ou le bug de pg_dump. Quelle sont les versions de PG (select version()) pg_dump (pg_dump --version) et eventuellement de PostGIS (si installé) ?
Les logs indiquent-ils des erreurs ou pb ? le disque contenant PG est-il plein ?

• Si le dump contient la création de la séquence apres la creation de la table, c'est normal que la restauration plante. (mais ca paraitrait bizarre que les sequences soit créées apres les tables.
(L'avantage de l'alias SERIAL est qu'il crée un lien entre la table et la sequence, lien utilisé pour l'export par pg_dump)

Dans le log de pg_dump en mode verbose, voyez ce genre de lignes apparaitre ?

Code:

...
pg_dump: recherche des colonnes et types de la table « test »
pg_dump: recherche des expressions par défaut de la table « test »
pg_dump: recherche des colonnes et types de la table « nouvelletable »
pg_dump: recherche des expressions par défaut de la table « nouvelletable »
...
pg_dump: création de SEQUENCE test_id_seq
...

Nicolas

Nicolas Granier · Mon 10 March 2014 11:35

Dans ma base à moi tout marche bien, la création de la table avec la méthode "nextval...sequence" fonctionne bien. C'est dans le dump que la séquence de cette table( créée par cette manière) n'est pas exportée; et donc à la restauration j'ai un message d'erreur me disant que la séquence n'existe pas.

Effectivement dans l'exemple que je donne, j'ai oublié de remettre de type de la donnée mais il y est bien, l'erreur n'est pas içi.

les versions sont les suivantes, j'ai deux versions de postgresql sur mon poste, un 9.1 et 9.2
pour pgdump

Code:

pg_dump (PostgreSQL) 9.2.2

pour ma base postgres/pgis

"PostgreSQL 9.1.8, compiled by Visual C++ build 1500, 64-bit"
"POSTGIS="2.0.1 r9979" GEOS="3.3.5-CAPI-1.7.5" PROJ="Rel. 4.8.0, 6 March 2012" LIBXML="2.7.8" LIBJSON="UNKNOWN""

Le disque n'est pas plein.

L'avantage de l'alias SERIAL est qu'il crée un lien entre la table et la sequence, lien utilisé pour l'export par pg_dump

C'est là mon problème, je cherche justement où est matérialisé ce lien afin de pouvoir le reconstituer, que je n'ai pas à passer par un pg_dump -t table_sequence

Je regarde les logs

Dernière modification par Nicolas Granier (Mon 10 March 2014 11:36)

Nicolas Granier · Mon 10 March 2014 12:22

Dans le retour du dump j'ai pour les anciennes tables, pour les parties en relation avec les séquences :

pg_dump: création de SEQUENCE t_table_c_pk_ident_seq
pg_dump: création de SEQUENCE OWNED BY t_table_c_pk_ident_seq
pg_dump: exécution de SEQUENCE SET t_table_c_pk_ident_seq
pg_dump: réglage du propriétaire et des droits pour SEQUENCE t_table_c_pk_ident_seq
pg_dump: réglage du propriétaire et des droits pour SEQUENCE OWNED BY t_table_c_pk_ident_seq

mais aucune mention de la séquence de ma nouvelle table (qui pose pb).

De même, en comparant les "recherches" et les "lectures" dans le log, j'ai la même chose, la recherche se fait sur les mêmes éléments entres anciennes et nouvelle table.

Dernière modification par Nicolas Granier (Mon 10 March 2014 12:24)

Nicolas Ribot · Mon 10 March 2014 15:53

Peut etre une incohérence dans l'export due aux différences de versions entre pg_dump et la base ?
Je vois qu'il y a eu des changements dans cet outil entre les versions 9.1.8 et 9.2.2 (http://www.postgresql.org/docs/9.3/static/release.html).

Il y a le meme probleme sur stackOverflow mais je ne comprends pas la réponse

http://stackoverflow.com/questions/1721 … om-pg-dump

Vous pouvez poster le code de création des tables et sequences, dans la base qui pose probleme ?
C'est un script SQL écrit ou un programme qui crée les objets de la base ?

Nicolas

Nicolas Ribot · Mon 10 March 2014 16:06

Des infos interessantes, là: http://grokbase.com/t/postgresql/pgsql- … ce-problem

Nicolas Granier · Tue 11 March 2014 08:42

Merci pour ces liens.
J'ai refait l'export avec la version de pg_dump inclue à postgresql 9.1 et pas d'amélioration.
Je vais investiguer les posts anglophones...
Au moins je ne suis pas seul à avoir le problème

Nicolas Granier · Tue 11 March 2014 10:26

Bonjour à tous,
J'ai trouvé et je comprend mieux maintenant les liens ci-dessus.
Ce qui m'a mis la puce à l'oreille c'est ce post : http://www.developpez.net/forums/d32830 … -sequence/ qui explique comment supprimer de manière brutale un lien vers une séquence.

En bref j'ai appliqué la requête suivante :

Code:

select * from pg_catalog.pg_depend WHERE objid in (SELECT oid FROM pg_catalog.pg_class WHERE relname = 't_tablenouvelle_seq')

La sous-requête me renvoie l'oid de l'objet et ensuite je liste depuis la table pg_depend , les dépendances associées. Certes ce ne sont que des identifiants un peu brut de décoffrage mais effectivement je n'ai qu'une ligne de dépendance quand dans toutes mes autres tables j'ai deux lignes.
J'étai parti pour faire un insert brutal des oid mais cette requête est plus adaptée :

Code:

 ALTER SEQUENCE t_tablenouvelle_seq OWNED BY t_t_tablenouvelle.identifiant;

C'est la ligne sql exportée dans le dump qui permet d'établir la possession.
Après exécution de la requête, génération du dump, tout est rentré dans l'ordre !

Merci à tous pour m'avoir mis sur la voie.

Communauté	Ressources	L'emploi	Le marché	L'association	Fils RSS
Forum Blogs Wiki Planet Sites amis	Agenda Biblio Fiches AMO-CNIG Paris PCGIS Téléchargements	Offres d'emploi Banque de CV Formations Démarche Métiers	Geo-Entreprises Geo-Communiqué Appels d'offres	L'association Qui sommes-nous ? Nous aider Bienfaiteurs Partenaires Historique Statuts	Tout le site Job Géomatique Services GeoBlogs ...	Faire un don Mentions légales

Le portail francophone de la géomatique

Annonce

#1 Thu 27 February 2014 17:16

POSTGRESQL : pg_dump - export de séquences

Code:

Code:

#2 Fri 28 February 2014 11:51

Re: POSTGRESQL : pg_dump - export de séquences

#3 Fri 28 February 2014 14:29

Re: POSTGRESQL : pg_dump - export de séquences

Code:

Code:

#4 Fri 28 February 2014 18:01

Re: POSTGRESQL : pg_dump - export de séquences

Code:

#5 Mon 03 March 2014 12:24

Re: POSTGRESQL : pg_dump - export de séquences

#6 Fri 07 March 2014 20:33

Re: POSTGRESQL : pg_dump - export de séquences

#7 Sat 08 March 2014 11:39

Re: POSTGRESQL : pg_dump - export de séquences

Code:

#8 Mon 10 March 2014 08:43

Re: POSTGRESQL : pg_dump - export de séquences

Code:

#9 Mon 10 March 2014 10:43

Re: POSTGRESQL : pg_dump - export de séquences

Code:

Code:

#10 Mon 10 March 2014 11:35

Re: POSTGRESQL : pg_dump - export de séquences

Code:

#11 Mon 10 March 2014 12:22

Re: POSTGRESQL : pg_dump - export de séquences

#12 Mon 10 March 2014 15:53

Re: POSTGRESQL : pg_dump - export de séquences

#13 Mon 10 March 2014 16:06

Re: POSTGRESQL : pg_dump - export de séquences

#14 Tue 11 March 2014 08:42

Re: POSTGRESQL : pg_dump - export de séquences

#15 Tue 11 March 2014 10:26

Re: POSTGRESQL : pg_dump - export de séquences

Code:

Code:

Pied de page des forums