Re: problem after upgrade db missing

Bonjour,

J'ai une BD qui semble fatiguée (messages d'erreurs disques il y a
quelques jours et tempr de traitements passé de 1 seconde à 15/20 mn).
J'essaie de la remonter sur une autre machine du réseau mais c'est
impossible :
Avec "pg_restore -d gesdil -c -v <gesdil_sv04"
J'obtiens :
pg_restore: suppression de CONSTRAINT stcn_pkey
pg_restore: [programme d'archives (db)] could not execute query :
ERREUR: La contrainte «stcn_pkey» n'existe pas pg_restore: *** annulé
à cause de l'erreur

avec "pg_restore -d gesdil -v <gesdil_sv04"
J'obtiens :
pg_restore: connexion à la base de données pour la
restauration pg_restore: création de ACL public
pg_restore: création de TABLE an
pg_restore: [programme d'archives (db)] could not execute query :
ERREUR: La relation «an» n'existe pas pg_restore: *** annulé à cause
de l'erreur

La sauvegarde est faite par :
pg_dump -Fc gesdil >/eur/ARCHIV/gesdil_sv${datej}

Le petit PC sur lequel Postgresql tourne semble en train de rendre
l'âme et il me semble important de récupérer la base au plus vite.

Si quelqu'un a une idée, merci d'avance ...

--
Alain
<eurlix(dot)alain(at)free(dot)fr>

Bonjour,

On Thu, 2012-04-05 at 15:52 +0200, Alain wrote:
> [...]
> J'ai une BD qui semble fatiguée (messages d'erreurs disques il y a
> quelques jours et tempr de traitements passé de 1 seconde à 15/20 mn).
> J'essaie de la remonter sur une autre machine du réseau mais c'est
> impossible :
> Avec "pg_restore -d gesdil -c -v <gesdil_sv04"
> J'obtiens :
> pg_restore: suppression de CONSTRAINT stcn_pkey
> pg_restore: [programme d'archives (db)] could not execute query :
> ERREUR: La contrainte «stcn_pkey» n'existe pas pg_restore: *** annulé
> à cause de l'erreur
>
> avec "pg_restore -d gesdil -v <gesdil_sv04"
> J'obtiens :
> pg_restore: connexion à la base de données pour la
> restauration pg_restore: création de ACL public
> pg_restore: création de TABLE an
> pg_restore: [programme d'archives (db)] could not execute query :
> ERREUR: La relation «an» n'existe pas pg_restore: *** annulé à cause
> de l'erreur
>

Très étonnant que vous ayez des messages d'erreur différents. C'est le
premier message d'erreur ou un au hasard ? Le plus important est d'avoir
le premier message.

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

On 04/05/2012 03:52 PM, Alain wrote:
> Bonjour,

Bonjour,

>
> J'ai une BD qui semble fatiguée (messages d'erreurs disques il y a
> quelques jours et tempr de traitements passé de 1 seconde à 15/20 mn).
> J'essaie de la remonter sur une autre machine du réseau mais c'est
> impossible :
> Avec "pg_restore -d gesdil -c -v <gesdil_sv04"
> J'obtiens :
> pg_restore: suppression de CONSTRAINT stcn_pkey
> pg_restore: [programme d'archives (db)] could not execute query :
> ERREUR: La contrainte «stcn_pkey» n'existe pas pg_restore: *** annulé
> à cause de l'erreur

Pourquoi utiliser l'option -c (clean) ? dans une DB vierge, c'est
inutile, et c'est la cause de l'erreur, il me semble.

> avec "pg_restore -d gesdil -v <gesdil_sv04"
> J'obtiens :
> pg_restore: connexion à la base de données pour la
> restauration pg_restore: création de ACL public
> pg_restore: création de TABLE an
> pg_restore: [programme d'archives (db)] could not execute query :
> ERREUR: La relation «an» n'existe pas pg_restore: *** annulé à cause
> de l'erreur

La redirection de l'entrée standard me semble inutile ; la commande
serait plutot :

pg_restore -d gesdil gesdil_sv04

> La sauvegarde est faite par :
> pg_dump -Fc gesdil >/eur/ARCHIV/gesdil_sv${datej}

Ça semble correct, c'est similaire à ce que je fait, et je n'ai pas de
problème avec ça

--
Sébastien Lardière
Hi-Media Nantes
DBA PostgreSQL
0228082071 / 0626595833

On Thu, 05 Apr 2012 16:56:53 +0200
Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote:

> Bonjour,
>
> On Thu, 2012-04-05 at 15:52 +0200, Alain wrote:
> > [...]
> > J'ai une BD qui semble fatiguée (messages d'erreurs disques il y a
> > quelques jours et tempr de traitements passé de 1 seconde à 15/20 mn).
> > J'essaie de la remonter sur une autre machine du réseau mais c'est
> > impossible :
> > Avec "pg_restore -d gesdil -c -v <gesdil_sv04"
> > J'obtiens :
> > pg_restore: suppression de CONSTRAINT stcn_pkey
> > pg_restore: [programme d'archives (db)] could not execute query :
> > ERREUR: La contrainte «stcn_pkey» n'existe pas pg_restore: *** annulé
> > à cause de l'erreur
> >
> > avec "pg_restore -d gesdil -v <gesdil_sv04"
> > J'obtiens :
> > pg_restore: connexion à la base de données pour la
> > restauration pg_restore: création de ACL public
> > pg_restore: création de TABLE an
> > pg_restore: [programme d'archives (db)] could not execute query :
> > ERREUR: La relation «an» n'existe pas pg_restore: *** annulé à cause
> > de l'erreur
> >
>
> Très étonnant que vous ayez des messages d'erreur différents. C'est le
> premier message d'erreur ou un au hasard ? Le plus important est d'avoir
> le premier message.
>
>
> --
> Guillaume
> http://blog.guillaume.lelarge.info
> http://www.dalibo.com
>
>
> --
> Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-fr-generale
>
Depuis deux jours j'ai recommencé plusieurs fois, en faisant quelques
essais tels que de créer les tables indiquées manquantes mais je
retombe toujours sur les mêmes erreurs ...
Ce sont de vieux PC (environ 7 ans) qui semblent avoir trop
réfléchis ;-) qui tournent avec Mandrake-Linux 10.1 et PostgreSQL 7.4.
Impossible du fait du hardware de passer à une version plus récente et
matériel et logiciel doivent être changé dans environ deux mois, mais
il faudrait que ça tourne encore deux ou trois mois.
J'en suis à tenter de récupérer les tables une par une ?

--
Alain <eurlix(dot)alain(at)free(dot)fr>

On Thu, 2012-04-05 at 17:27 +0200, Alain wrote:
> On Thu, 05 Apr 2012 16:56:53 +0200
> Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote:
>
> > Bonjour,
> >
> > On Thu, 2012-04-05 at 15:52 +0200, Alain wrote:
> > > [...]
> > > J'ai une BD qui semble fatiguée (messages d'erreurs disques il y a
> > > quelques jours et tempr de traitements passé de 1 seconde à 15/20 mn).
> > > J'essaie de la remonter sur une autre machine du réseau mais c'est
> > > impossible :
> > > Avec "pg_restore -d gesdil -c -v <gesdil_sv04"
> > > J'obtiens :
> > > pg_restore: suppression de CONSTRAINT stcn_pkey
> > > pg_restore: [programme d'archives (db)] could not execute query :
> > > ERREUR: La contrainte «stcn_pkey» n'existe pas pg_restore: *** annulé
> > > à cause de l'erreur
> > >
> > > avec "pg_restore -d gesdil -v <gesdil_sv04"
> > > J'obtiens :
> > > pg_restore: connexion à la base de données pour la
> > > restauration pg_restore: création de ACL public
> > > pg_restore: création de TABLE an
> > > pg_restore: [programme d'archives (db)] could not execute query :
> > > ERREUR: La relation «an» n'existe pas pg_restore: *** annulé à cause
> > > de l'erreur
> > >
> >
> > Très étonnant que vous ayez des messages d'erreur différents. C'est le
> > premier message d'erreur ou un au hasard ? Le plus important est d'avoir
> > le premier message.
> >
> >
> > --
> > Guillaume
> > http://blog.guillaume.lelarge.info
> > http://www.dalibo.com
> >
> >
> > --
> > Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-fr-generale
> >
> Depuis deux jours j'ai recommencé plusieurs fois, en faisant quelques
> essais tels que de créer les tables indiquées manquantes mais je
> retombe toujours sur les mêmes erreurs ...

Pas nécessaire.

> Ce sont de vieux PC (environ 7 ans) qui semblent avoir trop
> réfléchis ;-) qui tournent avec Mandrake-Linux 10.1 et PostgreSQL 7.4.
> Impossible du fait du hardware de passer à une version plus récente et
> matériel et logiciel doivent être changé dans environ deux mois, mais
> il faudrait que ça tourne encore deux ou trois mois.
> J'en suis à tenter de récupérer les tables une par une ?
>

Non, il faut reprendre ça calmement. Vous créez une nouvelle base, vous
essayez de restaurer votre sauvegarde sur cette base (sans utiliser
l'option -c comme le dit Sébastien) et vous regardez le premier message
d'erreur.

Si vous voulez qu'on vous aide, il va falloir être plus précis :
qu'est-ce que vous avez fait, quel est le premier message d'erreur que
vous avez reçu, etc.

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

On 04/05/2012 06:07 PM, Alain wrote:
> Avec ou sans "-c" (essayé d'abord sans, puis avec car les tables
> semblent crées, le résultat est quasiment identique ; toujours une
> erreur mais pas la même, comme indiqué précédemment.
> J'ai commencé sans la redirection de l'entrée standard, que j'ai
> rajouté après lecture de la doc. Il me semble qu'avec ou sans, ça
> revient au même pour postgres.

Oui, mais avec le -c, l'erreur que vous donnez est qu'il ne peut pas
dropper un objet (qui n'existe pas dans une DB vierge), donc, ça ne nous
avance pas.

Avez-vous des erreurs lors du pg_dump ?

Pouvez-vous essayer la commande suivante :

pg_restore --list gesdil_sv04

?

Vous devriez voir la liste des objets, sous forme de catalogues. Si
pg_restore sait faire cela, c'est que le dump n'est pas trop mauvais.

De même la commande suivante :

pg_restore -s gesdil_sv04

permet de générer les DDL des objets, vous devriez retrouver vos tables,
entres autres.

--
Sébastien Lardière
Hi-Media Nantes
DBA PostgreSQL
0228082071 / 0626595833

On Thu, 05 Apr 2012 17:37:12 +0200
Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote:

> On Thu, 2012-04-05 at 17:27 +0200, Alain wrote:
> > On Thu, 05 Apr 2012 16:56:53 +0200
> > Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote:
> >
> > > Bonjour,
> > >
> > > On Thu, 2012-04-05 at 15:52 +0200, Alain wrote:
> > > > [...]
> > > > J'ai une BD qui semble fatiguée (messages d'erreurs disques il y a
> > > > quelques jours et tempr de traitements passé de 1 seconde à 15/20 mn).
> > > > J'essaie de la remonter sur une autre machine du réseau mais c'est
> > > > impossible :
> > > > Avec "pg_restore -d gesdil -c -v <gesdil_sv04"
> > > > J'obtiens :
> > > > pg_restore: suppression de CONSTRAINT stcn_pkey
> > > > pg_restore: [programme d'archives (db)] could not execute query :
> > > > ERREUR: La contrainte «stcn_pkey» n'existe pas pg_restore: *** annulé
> > > > à cause de l'erreur
> > > >
> > > > avec "pg_restore -d gesdil -v <gesdil_sv04"
> > > > J'obtiens :
> > > > pg_restore: connexion à la base de données pour la
> > > > restauration pg_restore: création de ACL public
> > > > pg_restore: création de TABLE an
> > > > pg_restore: [programme d'archives (db)] could not execute query :
> > > > ERREUR: La relation «an» n'existe pas pg_restore: *** annulé à cause
> > > > de l'erreur
> > > >
> > >
> > > Très étonnant que vous ayez des messages d'erreur différents. C'est le
> > > premier message d'erreur ou un au hasard ? Le plus important est d'avoir
> > > le premier message.
> > >
> > >
> > > --
> > > Guillaume
> > > http://blog.guillaume.lelarge.info
> > > http://www.dalibo.com
> > >
> > >
> > > --
> > > Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> > > To make changes to your subscription:
> > > http://www.postgresql.org/mailpref/pgsql-fr-generale
> > >
> > Depuis deux jours j'ai recommencé plusieurs fois, en faisant quelques
> > essais tels que de créer les tables indiquées manquantes mais je
> > retombe toujours sur les mêmes erreurs ...
>
> Pas nécessaire.
>
> > Ce sont de vieux PC (environ 7 ans) qui semblent avoir trop
> > réfléchis ;-) qui tournent avec Mandrake-Linux 10.1 et PostgreSQL 7.4.
> > Impossible du fait du hardware de passer à une version plus récente et
> > matériel et logiciel doivent être changé dans environ deux mois, mais
> > il faudrait que ça tourne encore deux ou trois mois.
> > J'en suis à tenter de récupérer les tables une par une ?
> >
>
> Non, il faut reprendre ça calmement. Vous créez une nouvelle base, vous
> essayez de restaurer votre sauvegarde sur cette base (sans utiliser
> l'option -c comme le dit Sébastien) et vous regardez le premier message
> d'erreur.
>
> Si vous voulez qu'on vous aide, il va falloir être plus précis :
> qu'est-ce que vous avez fait, quel est le premier message d'erreur que
> vous avez reçu, etc.
>
>
> --
> Guillaume
> http://blog.guillaume.lelarge.info
> http://www.dalibo.com
>

Autant que je me rappelle, le premier message d'erreur concernait un
utilisateur occasionnel (jeanne) qui n'était pas créé sur ce PC. J'au
créé l'utilisateur et relancé.
J'avais avant créée la BD "gesdil", ce qui n'était sans doute pas
indispensable.
J'avais peut-être lancé initialement la restauration sans le "-c" et
certainement sans la redirection. J'ai ensuite ajouté le "-c" car la
majeure partie des tables sont créées (98/102).
Ça fait deux jours (et une partie des nuits) que je bataille sur ce
problème et mes souvenirs peuvent être un peu confus.
Je pourrais maintenant faire un "dropdb" qui me remettrait dans la
situation initiale et recommencer à zéro ?

--
Alain <eurlix(dot)alain(at)free(dot)fr>

On Thu, 2012-04-05 at 18:25 +0200, Alain wrote:
> On Thu, 05 Apr 2012 17:37:12 +0200
> Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote:
>
> > On Thu, 2012-04-05 at 17:27 +0200, Alain wrote:
> > > On Thu, 05 Apr 2012 16:56:53 +0200
> > > Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote:
> > >
> > > > Bonjour,
> > > >
> > > > On Thu, 2012-04-05 at 15:52 +0200, Alain wrote:
> > > > > [...]
> > > > > J'ai une BD qui semble fatiguée (messages d'erreurs disques il y a
> > > > > quelques jours et tempr de traitements passé de 1 seconde à 15/20 mn).
> > > > > J'essaie de la remonter sur une autre machine du réseau mais c'est
> > > > > impossible :
> > > > > Avec "pg_restore -d gesdil -c -v <gesdil_sv04"
> > > > > J'obtiens :
> > > > > pg_restore: suppression de CONSTRAINT stcn_pkey
> > > > > pg_restore: [programme d'archives (db)] could not execute query :
> > > > > ERREUR: La contrainte «stcn_pkey» n'existe pas pg_restore: *** annulé
> > > > > à cause de l'erreur
> > > > >
> > > > > avec "pg_restore -d gesdil -v <gesdil_sv04"
> > > > > J'obtiens :
> > > > > pg_restore: connexion à la base de données pour la
> > > > > restauration pg_restore: création de ACL public
> > > > > pg_restore: création de TABLE an
> > > > > pg_restore: [programme d'archives (db)] could not execute query :
> > > > > ERREUR: La relation «an» n'existe pas pg_restore: *** annulé à cause
> > > > > de l'erreur
> > > > >
> > > >
> > > > Très étonnant que vous ayez des messages d'erreur différents. C'est le
> > > > premier message d'erreur ou un au hasard ? Le plus important est d'avoir
> > > > le premier message.
> > > >
> > > >
> > > > --
> > > > Guillaume
> > > > http://blog.guillaume.lelarge.info
> > > > http://www.dalibo.com
> > > >
> > > >
> > > > --
> > > > Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> > > > To make changes to your subscription:
> > > > http://www.postgresql.org/mailpref/pgsql-fr-generale
> > > >
> > > Depuis deux jours j'ai recommencé plusieurs fois, en faisant quelques
> > > essais tels que de créer les tables indiquées manquantes mais je
> > > retombe toujours sur les mêmes erreurs ...
> >
> > Pas nécessaire.
> >
> > > Ce sont de vieux PC (environ 7 ans) qui semblent avoir trop
> > > réfléchis ;-) qui tournent avec Mandrake-Linux 10.1 et PostgreSQL 7.4.
> > > Impossible du fait du hardware de passer à une version plus récente et
> > > matériel et logiciel doivent être changé dans environ deux mois, mais
> > > il faudrait que ça tourne encore deux ou trois mois.
> > > J'en suis à tenter de récupérer les tables une par une ?
> > >
> >
> > Non, il faut reprendre ça calmement. Vous créez une nouvelle base, vous
> > essayez de restaurer votre sauvegarde sur cette base (sans utiliser
> > l'option -c comme le dit Sébastien) et vous regardez le premier message
> > d'erreur.
> >
> > Si vous voulez qu'on vous aide, il va falloir être plus précis :
> > qu'est-ce que vous avez fait, quel est le premier message d'erreur que
> > vous avez reçu, etc.
> >
> >
> > --
> > Guillaume
> > http://blog.guillaume.lelarge.info
> > http://www.dalibo.com
> >
>
> Autant que je me rappelle, le premier message d'erreur concernait un
> utilisateur occasionnel (jeanne) qui n'était pas créé sur ce PC. J'au
> créé l'utilisateur et relancé.
> J'avais avant créée la BD "gesdil", ce qui n'était sans doute pas
> indispensable.
> J'avais peut-être lancé initialement la restauration sans le "-c" et
> certainement sans la redirection. J'ai ensuite ajouté le "-c" car la
> majeure partie des tables sont créées (98/102).
> Ça fait deux jours (et une partie des nuits) que je bataille sur ce
> problème et mes souvenirs peuvent être un peu confus.
> Je pourrais maintenant faire un "dropdb" qui me remettrait dans la
> situation initiale et recommencer à zéro ?
>

Ça devrait être le cas avant chaque nouvelle tentative. Sinon vous allez
récupérer des erreurs des objets qui ont pu quand même être créés la
fois précédente et ne peuvent donc plus l'être maintenant.

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

On 04/05/2012 06:25 PM, Alain wrote:
>
> Autant que je me rappelle, le premier message d'erreur concernait un
> utilisateur occasionnel (jeanne) qui n'était pas créé sur ce PC. J'au
> créé l'utilisateur et relancé.

En effet, les objets globaux ne sont pas créés par pg_restore.

Pour ce type d'objets, vous pouvez utiliser pg_dumpall -g, afin de
récupérer la liste des users et groups

> J'avais avant créée la BD "gesdil", ce qui n'était sans doute pas
> indispensable.
> J'avais peut-être lancé initialement la restauration sans le "-c" et
> certainement sans la redirection. J'ai ensuite ajouté le "-c" car la
> majeure partie des tables sont créées (98/102).
> Ça fait deux jours (et une partie des nuits) que je bataille sur ce
> problème et mes souvenirs peuvent être un peu confus.
> Je pourrais maintenant faire un "dropdb" qui me remettrait dans la
> situation initiale et recommencer à zéro ?
>

Je vous conseille en effet cette option (dropdb puis createdb à
nouveau), vous êtes certains d'obtenir une DB vierge, et vous minimisez
le risque d'erreurs.

--
Sébastien Lardière
Hi-Media Nantes
DBA PostgreSQL
0228082071 / 0626595833

On Thu, 05 Apr 2012 18:38:51 +0200
Sébastien Lardière <slardiere(at)hi-media(dot)com> wrote:

> On 04/05/2012 06:25 PM, Alain wrote:
> >
> > Autant que je me rappelle, le premier message d'erreur concernait un
> > utilisateur occasionnel (jeanne) qui n'était pas créé sur ce PC. J'au
> > créé l'utilisateur et relancé.
>
> En effet, les objets globaux ne sont pas créés par pg_restore.
>
> Pour ce type d'objets, vous pouvez utiliser pg_dumpall -g, afin de
> récupérer la liste des users et groups
>
> > J'avais avant créée la BD "gesdil", ce qui n'était sans doute pas
> > indispensable.
> > J'avais peut-être lancé initialement la restauration sans le "-c" et
> > certainement sans la redirection. J'ai ensuite ajouté le "-c" car la
> > majeure partie des tables sont créées (98/102).
> > Ça fait deux jours (et une partie des nuits) que je bataille sur ce
> > problème et mes souvenirs peuvent être un peu confus.
> > Je pourrais maintenant faire un "dropdb" qui me remettrait dans la
> > situation initiale et recommencer à zéro ?
> >
>
> Je vous conseille en effet cette option (dropdb puis createdb à
> nouveau), vous êtes certains d'obtenir une DB vierge, et vous minimisez
> le risque d'erreurs.
>
> --
> Sébastien Lardière
> Hi-Media Nantes
> DBA PostgreSQL
> 0228082071 / 0626595833
>
>
> --
> Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-fr-generale
>
Vous n'avez sans doute pas reçu mon message précédent envoyé sous un
mauvais nom (pas abonné) :
Pas de message d'erreur lors du pg_dump, précédé par un vacuum.

J'ai lancé : pg_restore --list gesdil_sv04
sans problème.

Pas de problème signalé non plus sur "pg_restore -l"
Par contre, pg_restore -s ne crée que 100 tables sur 102,
sans les commentaires ce qui rend difficile le diff,
Des 2 tables manquantes, l'une est temporaire et vide, mais l'autre, la
table des articles est la principale (855 563 éléments) et c'est la
principale.

Les autres tables créées sont vides, évidemment ...

J'ai depuis fait dropdb puis createdb et pg_restore, la base se charge,
mais avec "-v", il risquait d'y en avoir pour un certain temps ...
J'ai cancellé puis relancé (en redirigeant la sortie dans un fichier)

J'aurai le résultat dans une ou deux heures, ou demain, ...
S'il manque une ou des tables, je pense arriver à les récupérer.

Merci pour votre aide, ainsi qu'à Guillaume Lelarge
--
Alain <eurlix(dot)alain(at)free(dot)fr>

On Thu, 5 Apr 2012 20:02:48 +0200
Alain <eurlix(dot)alain(at)free(dot)fr> wrote:

> On Thu, 05 Apr 2012 18:38:51 +0200
> Sébastien Lardière <slardiere(at)hi-media(dot)com> wrote:
>
> > On 04/05/2012 06:25 PM, Alain wrote:
> > >
> > > Autant que je me rappelle, le premier message d'erreur concernait un
> > > utilisateur occasionnel (jeanne) qui n'était pas créé sur ce PC. J'au
> > > créé l'utilisateur et relancé.
> >
> > En effet, les objets globaux ne sont pas créés par pg_restore.
> >
> > Pour ce type d'objets, vous pouvez utiliser pg_dumpall -g, afin de
> > récupérer la liste des users et groups
> >
> > > J'avais avant créée la BD "gesdil", ce qui n'était sans doute pas
> > > indispensable.
> > > J'avais peut-être lancé initialement la restauration sans le "-c" et
> > > certainement sans la redirection. J'ai ensuite ajouté le "-c" car la
> > > majeure partie des tables sont créées (98/102).
> > > Ça fait deux jours (et une partie des nuits) que je bataille sur ce
> > > problème et mes souvenirs peuvent être un peu confus.
> > > Je pourrais maintenant faire un "dropdb" qui me remettrait dans la
> > > situation initiale et recommencer à zéro ?
> > >
> >
> > Je vous conseille en effet cette option (dropdb puis createdb à
> > nouveau), vous êtes certains d'obtenir une DB vierge, et vous minimisez
> > le risque d'erreurs.
> >
> > --
> > Sébastien Lardière
> > Hi-Media Nantes
> > DBA PostgreSQL
> > 0228082071 / 0626595833
> >
> >
> > --
> > Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-fr-generale
> >
> Vous n'avez sans doute pas reçu mon message précédent envoyé sous un
> mauvais nom (pas abonné) :
> Pas de message d'erreur lors du pg_dump, précédé par un vacuum.
>
> J'ai lancé : pg_restore --list gesdil_sv04
> sans problème.
>
> Pas de problème signalé non plus sur "pg_restore -l"
> Par contre, pg_restore -s ne crée que 100 tables sur 102,
> sans les commentaires ce qui rend difficile le diff,
> Des 2 tables manquantes, l'une est temporaire et vide, mais l'autre, la
> table des articles est la principale (855 563 éléments) et c'est la
> principale.
>
> Les autres tables créées sont vides, évidemment ...
>
>
> J'ai depuis fait dropdb puis createdb et pg_restore, la base se charge,
> mais avec "-v", il risquait d'y en avoir pour un certain temps ...
> J'ai cancellé puis relancé (en redirigeant la sortie dans un fichier)
>
> J'aurai le résultat dans une ou deux heures, ou demain, ...
> S'il manque une ou des tables, je pense arriver à les récupérer.
>
> Merci pour votre aide, ainsi qu'à Guillaume Lelarge
> --
> Alain <eurlix(dot)alain(at)free(dot)fr>
>
> --
> Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-fr-generale
>
Bonsoir,

J'ai crié victoire un peu trop tôt :
pg_restore a planté silencieusement et la BD gesdil est vide.
(Même les tables crées par "pg_restore -s " ont disparu.

J'en reviens à l'idée de restaurer les tables une par une (il n'y en a
qu'une centaine et je dois pouvoir faire un script pour ça).

Avez-vous une autre idée ?

--
Alain <eurlix(dot)alain(at)free(dot)fr>

On Thu, 2012-04-05 at 21:03 +0200, Alain wrote:
> On Thu, 5 Apr 2012 20:02:48 +0200
> Alain <eurlix(dot)alain(at)free(dot)fr> wrote:
>
> > On Thu, 05 Apr 2012 18:38:51 +0200
> > Sébastien Lardière <slardiere(at)hi-media(dot)com> wrote:
> >
> > > On 04/05/2012 06:25 PM, Alain wrote:
> > > >
> > > > Autant que je me rappelle, le premier message d'erreur concernait un
> > > > utilisateur occasionnel (jeanne) qui n'était pas créé sur ce PC. J'au
> > > > créé l'utilisateur et relancé.
> > >
> > > En effet, les objets globaux ne sont pas créés par pg_restore.
> > >
> > > Pour ce type d'objets, vous pouvez utiliser pg_dumpall -g, afin de
> > > récupérer la liste des users et groups
> > >
> > > > J'avais avant créée la BD "gesdil", ce qui n'était sans doute pas
> > > > indispensable.
> > > > J'avais peut-être lancé initialement la restauration sans le "-c" et
> > > > certainement sans la redirection. J'ai ensuite ajouté le "-c" car la
> > > > majeure partie des tables sont créées (98/102).
> > > > Ça fait deux jours (et une partie des nuits) que je bataille sur ce
> > > > problème et mes souvenirs peuvent être un peu confus.
> > > > Je pourrais maintenant faire un "dropdb" qui me remettrait dans la
> > > > situation initiale et recommencer à zéro ?
> > > >
> > >
> > > Je vous conseille en effet cette option (dropdb puis createdb à
> > > nouveau), vous êtes certains d'obtenir une DB vierge, et vous minimisez
> > > le risque d'erreurs.
> > >
> > > --
> > > Sébastien Lardière
> > > Hi-Media Nantes
> > > DBA PostgreSQL
> > > 0228082071 / 0626595833
> > >
> > >
> > > --
> > > Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> > > To make changes to your subscription:
> > > http://www.postgresql.org/mailpref/pgsql-fr-generale
> > >
> > Vous n'avez sans doute pas reçu mon message précédent envoyé sous un
> > mauvais nom (pas abonné) :
> > Pas de message d'erreur lors du pg_dump, précédé par un vacuum.
> >
> > J'ai lancé : pg_restore --list gesdil_sv04
> > sans problème.
> >
> > Pas de problème signalé non plus sur "pg_restore -l"
> > Par contre, pg_restore -s ne crée que 100 tables sur 102,
> > sans les commentaires ce qui rend difficile le diff,
> > Des 2 tables manquantes, l'une est temporaire et vide, mais l'autre, la
> > table des articles est la principale (855 563 éléments) et c'est la
> > principale.
> >
> > Les autres tables créées sont vides, évidemment ...
> >
> >
> > J'ai depuis fait dropdb puis createdb et pg_restore, la base se charge,
> > mais avec "-v", il risquait d'y en avoir pour un certain temps ...
> > J'ai cancellé puis relancé (en redirigeant la sortie dans un fichier)
> >
> > J'aurai le résultat dans une ou deux heures, ou demain, ...
> > S'il manque une ou des tables, je pense arriver à les récupérer.
> >
> > Merci pour votre aide, ainsi qu'à Guillaume Lelarge
> > --
> > Alain <eurlix(dot)alain(at)free(dot)fr>
> >
> > --
> > Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-fr-generale
> >
> Bonsoir,
>
> J'ai crié victoire un peu trop tôt :
> pg_restore a planté silencieusement et la BD gesdil est vide.
> (Même les tables crées par "pg_restore -s " ont disparu.
>
> J'en reviens à l'idée de restaurer les tables une par une (il n'y en a
> qu'une centaine et je dois pouvoir faire un script pour ça).
>
> Avez-vous une autre idée ?
>

Comme déjà dit, sans plus de rigueur, on n'y arrivera pas. Votre
pg_restore plante sur quoi ? le lancez-vous sur une base vide ? avec
quelles options ?

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

On Thu, 2012-04-05 at 21:19 +0200, Guillaume Lelarge wrote:
> On Thu, 2012-04-05 at 21:03 +0200, Alain wrote:
> > On Thu, 5 Apr 2012 20:02:48 +0200
> > Alain <eurlix(dot)alain(at)free(dot)fr> wrote:
> >
> > > On Thu, 05 Apr 2012 18:38:51 +0200
> > > Sébastien Lardière <slardiere(at)hi-media(dot)com> wrote:
> > >
> > > > On 04/05/2012 06:25 PM, Alain wrote:
> > > > >
> > > > > Autant que je me rappelle, le premier message d'erreur concernait un
> > > > > utilisateur occasionnel (jeanne) qui n'était pas créé sur ce PC. J'au
> > > > > créé l'utilisateur et relancé.
> > > >
> > > > En effet, les objets globaux ne sont pas créés par pg_restore.
> > > >
> > > > Pour ce type d'objets, vous pouvez utiliser pg_dumpall -g, afin de
> > > > récupérer la liste des users et groups
> > > >
> > > > > J'avais avant créée la BD "gesdil", ce qui n'était sans doute pas
> > > > > indispensable.
> > > > > J'avais peut-être lancé initialement la restauration sans le "-c" et
> > > > > certainement sans la redirection. J'ai ensuite ajouté le "-c" car la
> > > > > majeure partie des tables sont créées (98/102).
> > > > > Ça fait deux jours (et une partie des nuits) que je bataille sur ce
> > > > > problème et mes souvenirs peuvent être un peu confus.
> > > > > Je pourrais maintenant faire un "dropdb" qui me remettrait dans la
> > > > > situation initiale et recommencer à zéro ?
> > > > >
> > > >
> > > > Je vous conseille en effet cette option (dropdb puis createdb à
> > > > nouveau), vous êtes certains d'obtenir une DB vierge, et vous minimisez
> > > > le risque d'erreurs.
> > > >
> > > > --
> > > > Sébastien Lardière
> > > > Hi-Media Nantes
> > > > DBA PostgreSQL
> > > > 0228082071 / 0626595833
> > > >
> > > >
> > > > --
> > > > Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> > > > To make changes to your subscription:
> > > > http://www.postgresql.org/mailpref/pgsql-fr-generale
> > > >
> > > Vous n'avez sans doute pas reçu mon message précédent envoyé sous un
> > > mauvais nom (pas abonné) :
> > > Pas de message d'erreur lors du pg_dump, précédé par un vacuum.
> > >
> > > J'ai lancé : pg_restore --list gesdil_sv04
> > > sans problème.
> > >
> > > Pas de problème signalé non plus sur "pg_restore -l"
> > > Par contre, pg_restore -s ne crée que 100 tables sur 102,
> > > sans les commentaires ce qui rend difficile le diff,
> > > Des 2 tables manquantes, l'une est temporaire et vide, mais l'autre, la
> > > table des articles est la principale (855 563 éléments) et c'est la
> > > principale.
> > >
> > > Les autres tables créées sont vides, évidemment ...
> > >
> > >
> > > J'ai depuis fait dropdb puis createdb et pg_restore, la base se charge,
> > > mais avec "-v", il risquait d'y en avoir pour un certain temps ...
> > > J'ai cancellé puis relancé (en redirigeant la sortie dans un fichier)
> > >
> > > J'aurai le résultat dans une ou deux heures, ou demain, ...
> > > S'il manque une ou des tables, je pense arriver à les récupérer.
> > >
> > > Merci pour votre aide, ainsi qu'à Guillaume Lelarge
> > > --
> > > Alain <eurlix(dot)alain(at)free(dot)fr>
> > >
> > > --
> > > Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> > > To make changes to your subscription:
> > > http://www.postgresql.org/mailpref/pgsql-fr-generale
> > >
> > Bonsoir,
> >
> > J'ai crié victoire un peu trop tôt :
> > pg_restore a planté silencieusement et la BD gesdil est vide.
> > (Même les tables crées par "pg_restore -s " ont disparu.
> >
> > J'en reviens à l'idée de restaurer les tables une par une (il n'y en a
> > qu'une centaine et je dois pouvoir faire un script pour ça).
> >
> > Avez-vous une autre idée ?
> >
>
> Comme déjà dit, sans plus de rigueur, on n'y arrivera pas. Votre
> pg_restore plante sur quoi ? le lancez-vous sur une base vide ? avec
> quelles options ?
>

Autre chose, si pg_restore ne dit rien, c'est qu'il a réussi ce que vous
lui avez demandé de faire. C'est pourquoi les options que vous lui avez
donné sont si importantes.

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

On Thu, 05 Apr 2012 21:20:57 +0200
Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote:

> On Thu, 2012-04-05 at 21:19 +0200, Guillaume Lelarge wrote:
> > On Thu, 2012-04-05 at 21:03 +0200, Alain wrote:
> > > On Thu, 5 Apr 2012 20:02:48 +0200
> > > Alain <eurlix(dot)alain(at)free(dot)fr> wrote:
> > >
> > > > On Thu, 05 Apr 2012 18:38:51 +0200
> > > > Sébastien Lardière <slardiere(at)hi-media(dot)com> wrote:
> > > >
> > > > > On 04/05/2012 06:25 PM, Alain wrote:
> > > > > >
> > > > > > Autant que je me rappelle, le premier message d'erreur concernait un
> > > > > > utilisateur occasionnel (jeanne) qui n'était pas créé sur ce PC. J'au
> > > > > > créé l'utilisateur et relancé.
> > > > >
> > > > > En effet, les objets globaux ne sont pas créés par pg_restore.
> > > > >
> > > > > Pour ce type d'objets, vous pouvez utiliser pg_dumpall -g, afin de
> > > > > récupérer la liste des users et groups
> > > > >
> > > > > > J'avais avant créée la BD "gesdil", ce qui n'était sans doute pas
> > > > > > indispensable.
> > > > > > J'avais peut-être lancé initialement la restauration sans le "-c" et
> > > > > > certainement sans la redirection. J'ai ensuite ajouté le "-c" car la
> > > > > > majeure partie des tables sont créées (98/102).
> > > > > > Ça fait deux jours (et une partie des nuits) que je bataille sur ce
> > > > > > problème et mes souvenirs peuvent être un peu confus.
> > > > > > Je pourrais maintenant faire un "dropdb" qui me remettrait dans la
> > > > > > situation initiale et recommencer à zéro ?
> > > > > >
> > > > >
> > > > > Je vous conseille en effet cette option (dropdb puis createdb à
> > > > > nouveau), vous êtes certains d'obtenir une DB vierge, et vous minimisez
> > > > > le risque d'erreurs.
> > > > >
> > > > > --
> > > > > Sébastien Lardière
> > > > > Hi-Media Nantes
> > > > > DBA PostgreSQL
> > > > > 0228082071 / 0626595833
> > > > >
> > > > >
> > > > > --
> > > > > Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> > > > > To make changes to your subscription:
> > > > > http://www.postgresql.org/mailpref/pgsql-fr-generale
> > > > >
> > > > Vous n'avez sans doute pas reçu mon message précédent envoyé sous un
> > > > mauvais nom (pas abonné) :
> > > > Pas de message d'erreur lors du pg_dump, précédé par un vacuum.
> > > >
> > > > J'ai lancé : pg_restore --list gesdil_sv04
> > > > sans problème.
> > > >
> > > > Pas de problème signalé non plus sur "pg_restore -l"
> > > > Par contre, pg_restore -s ne crée que 100 tables sur 102,
> > > > sans les commentaires ce qui rend difficile le diff,
> > > > Des 2 tables manquantes, l'une est temporaire et vide, mais l'autre, la
> > > > table des articles est la principale (855 563 éléments) et c'est la
> > > > principale.
> > > >
> > > > Les autres tables créées sont vides, évidemment ...
> > > >
> > > >
> > > > J'ai depuis fait dropdb puis createdb et pg_restore, la base se charge,
> > > > mais avec "-v", il risquait d'y en avoir pour un certain temps ...
> > > > J'ai cancellé puis relancé (en redirigeant la sortie dans un fichier)
> > > >
> > > > J'aurai le résultat dans une ou deux heures, ou demain, ...
> > > > S'il manque une ou des tables, je pense arriver à les récupérer.
> > > >
> > > > Merci pour votre aide, ainsi qu'à Guillaume Lelarge
> > > > --
> > > > Alain <eurlix(dot)alain(at)free(dot)fr>
> > > >
> > > > --
> > > > Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> > > > To make changes to your subscription:
> > > > http://www.postgresql.org/mailpref/pgsql-fr-generale
> > > >
> > > Bonsoir,
> > >
> > > J'ai crié victoire un peu trop tôt :
> > > pg_restore a planté silencieusement et la BD gesdil est vide.
> > > (Même les tables crées par "pg_restore -s " ont disparu.
> > >
> > > J'en reviens à l'idée de restaurer les tables une par une (il n'y en a
> > > qu'une centaine et je dois pouvoir faire un script pour ça).
> > >
> > > Avez-vous une autre idée ?
> > >
> >
> > Comme déjà dit, sans plus de rigueur, on n'y arrivera pas. Votre
> > pg_restore plante sur quoi ? le lancez-vous sur une base vide ? avec
> > quelles options ?
> >
>
> Autre chose, si pg_restore ne dit rien, c'est qu'il a réussi ce que vous
> lui avez demandé de faire. C'est pourquoi les options que vous lui avez
> donné sont si importantes.
>
>
> --
> Guillaume
> http://blog.guillaume.lelarge.info
> http://www.dalibo.com
>
>
Comme indiqué par Sébastien Lardière, j'ai à chaque fois fait
"dropdb gesdil" puis "createdb gesdil"
Je l'ai lance comme ça :
$ pg_restore gesdil_sv04 >restore.como 2>&1 &
[1] 18438
et j'ai obtenu ceci :
-rw-rw-r-- 1 auberon auberon 228982784 avr 5 21:00 restore.como
Mais au final la BD gesdil était vide !
(Même plus les tables crées par pg_restore -s )
Ça parait aberrant, car il n'y avait pas de -v, mais j'ai considéré
qu'il avait conservé qqchose du lancement précédent, avec -v, que
j'avais breaké !

Je viens de réussir à remonter la sauvegarde d'aujourd'hui, gesdil_sv05
et il me reste à faire que les requêtes soient traitées sur cette
machine.
J'ai changé PGHOSTADDR, après avoir modifié pg_hba.conf, mais ça ne
semble pas suffisant.

--
Alain <eurlix(dot)alain(at)free(dot)fr>

Bonsoir,

Le 5 avr. 2012 à 22:15, Alain a écrit :

> On Thu, 05 Apr 2012 21:20:57 +0200
> Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote:
>
>> On Thu, 2012-04-05 at 21:19 +0200, Guillaume Lelarge wrote:
>>> On Thu, 2012-04-05 at 21:03 +0200, Alain wrote:
>>>> On Thu, 5 Apr 2012 20:02:48 +0200
>>>> Alain <eurlix(dot)alain(at)free(dot)fr> wrote:
>>>>
>>>>> On Thu, 05 Apr 2012 18:38:51 +0200
>>>>> Sébastien Lardière <slardiere(at)hi-media(dot)com> wrote:
>>>>>
>>>>>> On 04/05/2012 06:25 PM, Alain wrote:
>>>>>>>
>>>>>>> Autant que je me rappelle, le premier message d'erreur concernait un
>>>>>>> utilisateur occasionnel (jeanne) qui n'était pas créé sur ce PC. J'au
>>>>>>> créé l'utilisateur et relancé.
>>>>>>
>>>>>> En effet, les objets globaux ne sont pas créés par pg_restore.
>>>>>>
>>>>>> Pour ce type d'objets, vous pouvez utiliser pg_dumpall -g, afin de
>>>>>> récupérer la liste des users et groups
>>>>>>
>>>>>>> J'avais avant créée la BD "gesdil", ce qui n'était sans doute pas
>>>>>>> indispensable.
>>>>>>> J'avais peut-être lancé initialement la restauration sans le "-c" et
>>>>>>> certainement sans la redirection. J'ai ensuite ajouté le "-c" car la
>>>>>>> majeure partie des tables sont créées (98/102).
>>>>>>> Ça fait deux jours (et une partie des nuits) que je bataille sur ce
>>>>>>> problème et mes souvenirs peuvent être un peu confus.
>>>>>>> Je pourrais maintenant faire un "dropdb" qui me remettrait dans la
>>>>>>> situation initiale et recommencer à zéro ?
>>>>>>>
>>>>>>
>>>>>> Je vous conseille en effet cette option (dropdb puis createdb à
>>>>>> nouveau), vous êtes certains d'obtenir une DB vierge, et vous minimisez
>>>>>> le risque d'erreurs.
>>>>>>
>>>>>> --
>>>>>> Sébastien Lardière
>>>>>> Hi-Media Nantes
>>>>>> DBA PostgreSQL
>>>>>> 0228082071 / 0626595833
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
>>>>>> To make changes to your subscription:
>>>>>> http://www.postgresql.org/mailpref/pgsql-fr-generale
>>>>>>
>>>>> Vous n'avez sans doute pas reçu mon message précédent envoyé sous un
>>>>> mauvais nom (pas abonné) :
>>>>> Pas de message d'erreur lors du pg_dump, précédé par un vacuum.
>>>>>
>>>>> J'ai lancé : pg_restore --list gesdil_sv04
>>>>> sans problème.
>>>>>
>>>>> Pas de problème signalé non plus sur "pg_restore -l"
>>>>> Par contre, pg_restore -s ne crée que 100 tables sur 102,
>>>>> sans les commentaires ce qui rend difficile le diff,
>>>>> Des 2 tables manquantes, l'une est temporaire et vide, mais l'autre, la
>>>>> table des articles est la principale (855 563 éléments) et c'est la
>>>>> principale.
>>>>>
>>>>> Les autres tables créées sont vides, évidemment ...
>>>>>
>>>>>
>>>>> J'ai depuis fait dropdb puis createdb et pg_restore, la base se charge,
>>>>> mais avec "-v", il risquait d'y en avoir pour un certain temps ...
>>>>> J'ai cancellé puis relancé (en redirigeant la sortie dans un fichier)
>>>>>
>>>>> J'aurai le résultat dans une ou deux heures, ou demain, ...
>>>>> S'il manque une ou des tables, je pense arriver à les récupérer.
>>>>>
>>>>> Merci pour votre aide, ainsi qu'à Guillaume Lelarge
>>>>> --
>>>>> Alain <eurlix(dot)alain(at)free(dot)fr>
>>>>>
>>>>> --
>>>>> Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
>>>>> To make changes to your subscription:
>>>>> http://www.postgresql.org/mailpref/pgsql-fr-generale
>>>>>
>>>> Bonsoir,
>>>>
>>>> J'ai crié victoire un peu trop tôt :
>>>> pg_restore a planté silencieusement et la BD gesdil est vide.
>>>> (Même les tables crées par "pg_restore -s " ont disparu.
>>>>
>>>> J'en reviens à l'idée de restaurer les tables une par une (il n'y en a
>>>> qu'une centaine et je dois pouvoir faire un script pour ça).
>>>>
>>>> Avez-vous une autre idée ?
>>>>
>>>
>>> Comme déjà dit, sans plus de rigueur, on n'y arrivera pas. Votre
>>> pg_restore plante sur quoi ? le lancez-vous sur une base vide ? avec
>>> quelles options ?
>>>
>>
>> Autre chose, si pg_restore ne dit rien, c'est qu'il a réussi ce que vous
>> lui avez demandé de faire. C'est pourquoi les options que vous lui avez
>> donné sont si importantes.
>>
>>
>> --
>> Guillaume
>> http://blog.guillaume.lelarge.info
>> http://www.dalibo.com
>>
>>
> Comme indiqué par Sébastien Lardière, j'ai à chaque fois fait
> "dropdb gesdil" puis "createdb gesdil"
> Je l'ai lance comme ça :
> $ pg_restore gesdil_sv04 >restore.como 2>&1 &
> [1] 18438
> et j'ai obtenu ceci :
> -rw-rw-r-- 1 auberon auberon 228982784 avr 5 21:00 restore.como
> Mais au final la BD gesdil était vide !
> (Même plus les tables crées par pg_restore -s )
> Ça parait aberrant, car il n'y avait pas de -v, mais j'ai considéré
> qu'il avait conservé qqchose du lancement précédent, avec -v, que
> j'avais breaké !

Il n'y a aucune aberration dans ce qu'il se produit. Regardez votre fichier restore.como, il s'agit d'un script SQL que pg_restore a généré à partir de votre fichier dump gesdil_sv04. En fait, vous n'indiquez pas à pg_restore de restaurer dans une base de données particulière. L'option -d nombase permet de le lui indiquer.
Essayez plutôt avec la commande pg_restore -d gesdil gesdil_sv04.

Cordialement,
Thomas

Alain wrote:

> Comme indiqué par Sébastien Lardière, j'ai à chaque fois fait
> "dropdb gesdil" puis "createdb gesdil"
> Je l'ai lance comme ça :
> $ pg_restore gesdil_sv04 >restore.como 2>&1 &

Mauvais plan.
En cas de messages d'erreur de pg_restore, le 2>&1 dit de les mettre un peu
comme ça vient en plein milieu des commandes SQL.
Du coup non seulement ils sont impossibles à repérer au milieu du SQL, mais
en plus les commandes SQL aussi sont potentiellement corrompues à cause de
ces messages.

Une invocation comme ça devrait suffir amplement:
$ pg_restore gesdil_sv04 >restore.como

et s'il faut conserver les éventuelles erreurs en fichier, les envoyer
ailleurs:
$ pg_restore gesdil_sv04 >restore.como 2>erreurs

Comme dit précedemment par Thomas, ça se contente de générer un fichier SQL
sans le jouer dans aucune base, mais c'est déjà pas mal.

Cordialement,
--
Daniel
PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org

On 04/05/2012 07:20 PM, Alain wrote:
> Pas de message d'erreur lors du pg_dump, précédé par un vacuum.
>
> J'ai lancé : pg_restore --list gesdil_sv04
> sans problème.
>
> Pas de problème signalé non plus sur "pg_restore -l"
> Par contre, pg_restore -s ne crée que 100 tables sur 102,
> sans les commentaires ce qui rend difficile le diff,
> Des 2 tables manquantes, l'une est temporaire et vide, mais l'autre, la
> table des articles est la principale (855 563 éléments) et c'est la
> principale.
>
> Les autres tables créées sont vides, évidemment ...

Bonjour,

Ces 2 commandes ne sont pas destinées à être utilisée pour restaurer la
DB, mais pour établir un diagnostic : si l'option --list retourne bien
de catalogue, c'est que le dump semble être correct, et si, avec
l'option -s (schema only), on obtient bien les ordres de création des
tables, alors cela confirme l'état du dump.

Une fois fait, un restore dans un base vierge devrait donner quelque
chose :

pg_restore -d gesdil gesdil_sv04 > gesdil.log 2>&1

va lancer le restore, et mettre tous les messages de sortie (std et err)
dans le fichier de log. Si tout va bien, le fichier sera vide, sinon, on
avisera en fonction du contenu du log.

--
Sébastien Lardière
Hi-Media Nantes
DBA PostgreSQL
0228082071 / 0626595833

On 04/05/2012 10:15 PM, Alain wrote:
> Je viens de réussir à remonter la sauvegarde d'aujourd'hui, gesdil_sv05
> et il me reste à faire que les requêtes soient traitées sur cette
> machine.
> J'ai changé PGHOSTADDR, après avoir modifié pg_hba.conf, mais ça ne
> semble pas suffisant.

Bon, nous ne saurons probablement pas pourquoi le dump précédent n'a pas
fonctionné, mais peu importe.

Pour la connexion, ne connaissant pas votre réseau, c'est difficile d'en
dire plus, mais, pour commencer, je vous propose d'installer la partie
cliente de PostgreSQL sur la machine ou vous avez modifié PGHOSTADDR, et
de tenté de vous connecter avec l'outil en ligne de commande psql. Les
messages d'erreurs éventuels nous aideront sûrement.

--
Sébastien Lardière
Hi-Media Nantes
DBA PostgreSQL
0228082071 / 0626595833

On Fri, 06 Apr 2012 09:53:04 +0200
Sébastien Lardière <slardiere(at)hi-media(dot)com> wrote:

> On 04/05/2012 10:15 PM, Alain wrote:
> > Je viens de réussir à remonter la sauvegarde d'aujourd'hui, gesdil_sv05
> > et il me reste à faire que les requêtes soient traitées sur cette
> > machine.
> > J'ai changé PGHOSTADDR, après avoir modifié pg_hba.conf, mais ça ne
> > semble pas suffisant.
>
> Bon, nous ne saurons probablement pas pourquoi le dump précédent n'a pas
> fonctionné, mais peu importe.
>
> Pour la connexion, ne connaissant pas votre réseau, c'est difficile d'en
> dire plus, mais, pour commencer, je vous propose d'installer la partie
> cliente de PostgreSQL sur la machine ou vous avez modifié PGHOSTADDR, et
> de tenté de vous connecter avec l'outil en ligne de commande psql. Les
> messages d'erreurs éventuels nous aideront sûrement.
>
>
> --
> Sébastien Lardière
> Hi-Media Nantes
> DBA PostgreSQL
> 0228082071 / 0626595833
>
>
> --
> Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-fr-generale
>
Effectivement, utiliser psql m'a aidé à faire fonctionner postgresql.
A ce moment là je me suis trouvé avec deux PC, l'un avec le logiciel,
l'autre (en fait les deux) avec la BD et toujours des temps de
traitement extrèmement longs (de l'ordre de 15mn ald 1s).
Pour essayer de résoudre le problème, nous avons cloné le PC1 sur une
machine plus récente, en virtualisation.

J'ai sauvegardé sur le PC2, transféré le resultat sur le PC3, puis
restauré par :
pg_restore -c gesdil_sv073 > gesdil_restore3.log 2>gesdil_restore3.err
Clairement, la BD n'était pas à jour du travail fait le 6/4.
La 2e et la 3e fois j'ai stoppé les instances de postgres sur PC1 et 2
avant de lancer la restauration.
La 4e fois, pour en avoir le coeur net, j'ai fait
[mpp(at)pc1 ARCHIV]$ dropdb gesdil
DROP DATABASE
[mpp(at)pc1 ARCHIV]$ createdb gesdil
CREATE DATABASE
La restauration semble bien se passer, mais
gesdil=# select cdenum, cdedate, cdecli from cde order by
cdedate ; ERREUR: La relation «cde» n'existe pas
gesdil=# \d+
Pas de relations trouvées.

Rien dans syslog, sauf
Apr 7 17:28:53 pc1 postgres[9455]: [1-1] ERREUR: La relation «cde»
n'existe pas
Où peut-il bien remonter la base ?

Merci d'avance,
--
Alain <eurlix(dot)alain(at)free(dot)fr>

On Sat, 2012-04-07 at 17:56 +0200, Alain wrote:
> On Fri, 06 Apr 2012 09:53:04 +0200
> Sébastien Lardière <slardiere(at)hi-media(dot)com> wrote:
>
> > On 04/05/2012 10:15 PM, Alain wrote:
> > > Je viens de réussir à remonter la sauvegarde d'aujourd'hui, gesdil_sv05
> > > et il me reste à faire que les requêtes soient traitées sur cette
> > > machine.
> > > J'ai changé PGHOSTADDR, après avoir modifié pg_hba.conf, mais ça ne
> > > semble pas suffisant.
> >
> > Bon, nous ne saurons probablement pas pourquoi le dump précédent n'a pas
> > fonctionné, mais peu importe.
> >
> > Pour la connexion, ne connaissant pas votre réseau, c'est difficile d'en
> > dire plus, mais, pour commencer, je vous propose d'installer la partie
> > cliente de PostgreSQL sur la machine ou vous avez modifié PGHOSTADDR, et
> > de tenté de vous connecter avec l'outil en ligne de commande psql. Les
> > messages d'erreurs éventuels nous aideront sûrement.
> >
> >
> > --
> > Sébastien Lardière
> > Hi-Media Nantes
> > DBA PostgreSQL
> > 0228082071 / 0626595833
> >
> >
> > --
> > Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-fr-generale
> >
> Effectivement, utiliser psql m'a aidé à faire fonctionner postgresql.
> A ce moment là je me suis trouvé avec deux PC, l'un avec le logiciel,
> l'autre (en fait les deux) avec la BD et toujours des temps de
> traitement extrèmement longs (de l'ordre de 15mn ald 1s).
> Pour essayer de résoudre le problème, nous avons cloné le PC1 sur une
> machine plus récente, en virtualisation.
>
> J'ai sauvegardé sur le PC2, transféré le resultat sur le PC3, puis
> restauré par :
> pg_restore -c gesdil_sv073 > gesdil_restore3.log 2>gesdil_restore3.err

Il manque le nom de la base où vous voulez restaurer la sauvegarde (en
supposant que le nom de la sauvegarde est gesdil_sv073.

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

On Sat, 2012-04-07 at 18:52 +0200, Alain wrote:
> On Sat, 07 Apr 2012 18:13:20 +0200
> Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote:
>
> > On Sat, 2012-04-07 at 17:56 +0200, Alain wrote:
> > > On Fri, 06 Apr 2012 09:53:04 +0200
> > > Sébastien Lardière <slardiere(at)hi-media(dot)com> wrote:
> > >
> > > > On 04/05/2012 10:15 PM, Alain wrote:
> > > > > Je viens de réussir à remonter la sauvegarde d'aujourd'hui, gesdil_sv05
> > > > > et il me reste à faire que les requêtes soient traitées sur cette
> > > > > machine.
> > > > > J'ai changé PGHOSTADDR, après avoir modifié pg_hba.conf, mais ça ne
> > > > > semble pas suffisant.
> > > >
> > > > Bon, nous ne saurons probablement pas pourquoi le dump précédent n'a pas
> > > > fonctionné, mais peu importe.
> > > >
> > > > Pour la connexion, ne connaissant pas votre réseau, c'est difficile d'en
> > > > dire plus, mais, pour commencer, je vous propose d'installer la partie
> > > > cliente de PostgreSQL sur la machine ou vous avez modifié PGHOSTADDR, et
> > > > de tenté de vous connecter avec l'outil en ligne de commande psql. Les
> > > > messages d'erreurs éventuels nous aideront sûrement.
> > > >
> > > >
> > > > --
> > > > Sébastien Lardière
> > > > Hi-Media Nantes
> > > > DBA PostgreSQL
> > > > 0228082071 / 0626595833
> > > >
> > > >
> > > > --
> > > > Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> > > > To make changes to your subscription:
> > > > http://www.postgresql.org/mailpref/pgsql-fr-generale
> > > >
> > > Effectivement, utiliser psql m'a aidé à faire fonctionner postgresql.
> > > A ce moment là je me suis trouvé avec deux PC, l'un avec le logiciel,
> > > l'autre (en fait les deux) avec la BD et toujours des temps de
> > > traitement extrèmement longs (de l'ordre de 15mn ald 1s).
> > > Pour essayer de résoudre le problème, nous avons cloné le PC1 sur une
> > > machine plus récente, en virtualisation.
> > >
> > > J'ai sauvegardé sur le PC2, transféré le resultat sur le PC3, puis
> > > restauré par :
> > > pg_restore -c gesdil_sv073 > gesdil_restore3.log 2>gesdil_restore3.err
> >
> > Il manque le nom de la base où vous voulez restaurer la sauvegarde (en
> > supposant que le nom de la sauvegarde est gesdil_sv073.
> >
> >
> > --
> > Guillaume
> > http://blog.guillaume.lelarge.info
> > http://www.dalibo.com
> >
> >
> J'ai relancé comme suit :
> [mpp(at)pc1 ARCHIV]$ pg_restore -dgesdil -c gesdil_sv073 >gesdil_restore3.log 2>gesdil_restor>
>
> C'est beaucoup plus rapide, mais le résultat ne change pas :
> [mpp(at)pc1 ARCHIV]$ psql gesdil
> Bienvenue dans psql 7.4.5, l'interface interactive de PostgreSQL.
>
> Tapez: \copyright pour les termes de distribution
> \h pour l'aide-mémoire sur les commandes SQL
> \? pour l'aide-mémoire sur les commandes internes
> \g ou terminez avec un point-virgule pour exécuter une requête
> \q pour quitter
>
> gesdil=# \d
> + Pas de relations trouvées.
>

Et qu'est-ce que vous donne un :

pg_restore -c gesdil_sv073

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

On 6/6/2012 2:35 AM, Daniel Verite wrote:
> Aleksander Rozman wrote:
>
>> Now I am not sure two of this directories are old databases, but I think
>> they are... Is there a way to register one of this databases into new
>> installation (I am sure that directory "1" is old postgres database, and
>> "11563" is my database I want to save, and "11564" is new postgresql
>> database (this is only directory with new date).
> Actually 1, 11563 and 11564 are what you get with a fresh new installation.
> On a 8.4 install on Ubuntu, the corresponding databases are:
>
> SELECT oid, datname from pg_database where oid in (1,11563,11564);
>
> oid | datname
> -------+-----------
> 1 | template1
> 11563 | template0
> 11564 | postgres
>
> Also normally initdb wouldn't work on a non-empty data directory, anyway.
> I'd say that either the old data directory has been moved aside at some point
> of the upgrade procedure, or it has been wiped out :(
>
> Best regards,
Problem is that upgrade of Ubuntu failed at some point, and after that I
did clean install... So database probably got deleted at some point.

Andy