Vous n'êtes pas identifié(e).
Bonjour,
Vous avez simplement oublié un WHERE dans votre requête (SELECT count(*) FROM MEMBRE WHERE login=).
Vous ne pouvez pas faire ça avec pg_dump.
COPY vous permet par contre de faire quelque chose de ce type (cf http://www.postgresql.org/docs/9.3/stat … copy.html)
Ce n'est ni un bug ni une évolution nécessaire, lorsque vous dumpez vos données, il est spécifier la PK existante dans la base source.
Lorsque vous réinsérez ces données, il ne va pas changer la PK car sinon les données ne seront plus cohérentes avec la source initiale.
Il faut comprendre que les données que vous insérez ne sont pas considérées comme de nouvelles données mais bien comme des données figées donc avec une PK figée.
Nous savons ce qu'est pg_restore, l'usage que vous en faites par contre ne semble pas être cohérent.
Les PK ne sont pas incrémentées automatiquement puisque que le dump contient la PK en dur.
Si des données sont déjà présentes dans votre table, il vous faut donc les enlever ou alors modifier les inserts du dump pour enlever les PK écrites en dur.
Pouvez-vous copier les requêtes exactes que vous lancez pour le dump et le restore (pas comme sur le premier post).
Car normalement le dump contient les pk donc pas besoin d'incrémenter vous même.
Si vous avez dumpé uniquement les données des tables associées, il est inutile de préciser lors du restore les tables que vous souhaitez restaurer (donc pas besoin des "-t")
Bonjour,
Pour le dump de vos tables, essayez ça : pg_dump -t "schema.table1" -t "schema.table2"
Bonjour,
Votre version de PhpPgAdmin est-elle à jour?
Bonjour,
EXPLAIN ANALYZE lance effectivement la requête et ne se limite pas à en afficher le plan théorique.
Vous pouvez vous baser sur le lien suivant : http://www.postgresql.org/docs/9.2/stat … tting.html
Il explique tout ça de manière complète.
Bonjour,
Je ne sais pas si c'est la méthode la plus efficace, mais pourquoi ne pas convertir le premier format de date en timestamp puis reconvertir celui-ci dans le format de date souhaité?
Bonjour,
Essayez de trouver le fichier "pgstartup.log" sur votre serveur. Suivant votre installation il ne sera pas forcément au même endroit. Un "locate pgstartup.log" devrait pouvoir vous indiquer son emplacement.
Sur redhat, vous pouvez le trouver, pour une installation normale, dans /var/lib/pgsql/9.X/
Avez-vous changé les variables d'environnement de votre utilisateur postgres? Car vous n'utilisez pas le service pour l'initdb mais directement le binaire.
Bonjour Ayat,
L'utilisateur postgres a-t-il les droits sur les répertoires précédents et non uniquement sur celui qui est destiné à contenir votre cluster ?
La variable principale est $PGDATA qui contient l'endroit où vous souhaitez placer votre cluster de base de données.
Par exemple, vous pouvez utiliser "yum remove" ou "rpm -e"
Il semblerait donc que vous ayez oublié de supprimer les RPM que vous avez installé.
Bonjour,
De quelle manière avez-vous désinstallé PostgreSQL 8.4?
Bonjour,
Si vous avez un doute, montez une infrastructure en preprod et testez qu'en 9.3 vous n'avez pas de problème.
Si vous êtes sûre du mot de passe de votre utilisateur postgres, vous pouvez le redéfinir de mot de passe de celui-ci avec le même mot de passe et réessayer.
Corrigez la ligne et mettez "127.0.0.1/32"
Vous n'avez pas d'autre erreur juste avant celle-ci?
Bonjour Marion_cdapp,
Il est parfaitement normal que vous n'ayez pas de fichier postmaster.pid, c'est lorsque vous lancez PostgreSQL que celui-ci sera créé.
Ce fichier n'est donc pas à créer manuellement.
Il faudrait demander ça directement à vos responsables réseau/sécurité car je ne connais pas l'architecture sur laquelle vous travaillez.
Si vous n'avez pas de composant entre les deux machines, oui il faut modifier sur le serveur A pour autoriser B à se connecter par le port 22.
