Vous n'êtes pas identifié(e).
Bonjour,
Après une migration quasi involontaire de Pgsql (en fait je suis passé d'Ubuntu 9.10 à 10.04 ce qui a provoqué cette migration de PostgreSQL), je n'ai pas retrouvé ma base de données sous Pgsql 8.4.
Heureusement j'avais un Pg_dump à jour
Malheureusemenr j'ai une table avec une colonne déclarée avec le type isbn13 sous pgsql 8.3
ce type ne semble pas être reconnu par pgsql 8.4
C'est la table la plus important de ma base
J'ai absolument besoin de vos idées
Merci d'avance
Hors ligne
Le type isbn13 est n'est pas un type par défaut de PostgreSQL. Pour l'avoir, il vous faut installer les modules contrib. Voir le paquet postgresql-contrib-8.4.
Guillaume.
Hors ligne
Merci,
Cela marche effectivement après installation du paquet contrib. malgré quelques messages d'erreurs (?)
Par contre, à mon grand dépit mon Pg_dump n'était pas à jour ;-(((
Est-il possible de repartir des fichiers de la base de données 8.3 ? (j'avais fait une image de mon PC avant la migration) et si oui où sont -ils ?
Grrr... c'est le métier qui rentre..
Hors ligne
Normalement, ils sont toujours dans leur ancien répertoire, à savoir /var/lib/postgresql/8.3/main ou quelque chose d'approchant. Par contre, il vous faut PostgreSQL 8.3 pour pouvoir lancer PostgreSQL sur ce répertoire.
Guillaume.
Hors ligne
question stupide :
si je recopie ces fichiers dans leur équivalent 8.4 (Pg arrêté of course) je vais à la catastrophe au redémarrage ?
Hors ligne
Catastrophe, non. Il ne démarrera pas, c'est tout. Entre deux versions majeures, les fichiers ne sont pas compatibles.
Guillaume.
Hors ligne
Le plus simple dans votre cas serait certainement de réinstaller la version 8.3. Mais pas sûr qu'ubuntu la propose.
Guillaume.
Hors ligne
Oui je m'y attendais
Merci de tes réponses rapides
peut-on faire cohabiter les 2 versions côte à côte ?
c'est peut-être un peu risqué en terme de config ??
à ta connaissance, il n'y a pas d'autre outil de migration que pg_dump ?
Hors ligne
peut-on faire cohabiter les 2 versions côte à côte ?
Oui, les packages de Debian sont fait pour. Et PostgreSQL accepte cela sans problème à condition évidemment que le port de connexion TCP soit différent.
c'est peut-être un peu risqué en terme de config ??
Non, pas du tout.
à ta connaissance, il n'y a pas d'autre outil de migration que pg_dump ?
Si, mais ils sont soit plus complexe (slony par exemple), soit moins testé (pg_migrator). Dans ton cas, pg_dump/pg_restore me semble la meilleure solution. Mais encore mieux et plus rapide, rester sous PostgreSQL 8.3.
Guillaume.
Hors ligne
Compte-tenu de la politique d'Ubuntu, je préfèrerais miger vers la 8.4 (je bénificierais ainsi des mises à jour de sécurité automatiques, etc..)
J'ai effectivement pu voir que ma base de données 8.3 était toujours là
Si je veux réinstaller la 8.3 juste le temps de refaire un pg_dump j'ai trouvé sur le site debian des paquets 8.3 pour une debian lenny (je ne sais pas si cela correspond à Ubuntu Lucid, je vais regarder ça) par contre comment cela va t'il se passer avec le user Postgres (qui a été créé lors de l'install de la 8.4) vais-je assister à un duel en bonne et due forme ??
Hors ligne
Peu importe pour le pg_dump, il vaut toujours mieux utiliser celui de la version sur laquelle va se faire la restauration (ie un pg_dump 8.4 si on veut le restaurer sur un serveur 8.4). Par contre, les fichiers de la 8.3 ne suffisent pas, il faut aussi avoir le moteur de la 8.3 car pg_dump est un client PostgreSQL comme les autres, il doit pouvoir se connecter à la base poru faire son office.
Guillaume.
Hors ligne
OK
La question que je me pose c'est de savoir comment réinstaller la 8.3 j'ai peur que l'install par des paquets debian ne cherche à recréer un user postgres qui existe déjà puisqu'il a été créé par l'install de la 8.4
de plus la reinstall de la 8.3 ne risque t-'elle pas d'effacer la base 8.3 que je cherche à récupérer
Hors ligne
Non, il n'y a aucun soucis à installer les deux.
Guillaume.
Hors ligne
ça y est, j'ai les deux versions en côte à côte et je vais pouvoir récupérer mes données
Merci de ton aide,
Yann
Hors ligne
Il y a même un pg_upgradecluster, sous Debian/Ubuntu, pour effectuer la migration 
Marc.
Hors ligne
Bonjour,
Je ne suis pas très expérimenté avec PostgreSQL et je rencontre le même problème lors d'une mise à jour de Debian Lenny vers Squeeze.
Debian m’a installé la version 8.4 de PostgreSQL en créant un nouveau cluster dans /var/lib/postgresql/8.4/. L’ancien cluster est toujours dans /var/lib/postgresql/8.3/.
Visiblement l’installation a laissé les répertoires /etc/postgresql/8.3 et /var/lib/postgresql/8.3/.
Dans les configurations 8.3 est configuré sur le port 5432 et 8.4 sur le port 5433.
Il faudrait que je puisse lancer PostgreSQL 8.3 afin d’utiliser pg_upgradecluster afin de migrer mes données du cluster 8.3 vers le cluster 8.4.
Mais… lorsque je lance /etc/init.d/postgresql start seul la version 8.4 se lance.
La commande /etc/init.d/postgresql start 8.3 ne fait rien. J’ai aussi un script /etc/init.d/postgresql-8.3. Celui me donne l’erreur suivante :
mainError: could not exec start -D /var/lib/postgresql/8.3/main -l /var/log/postgresql/postgresql-8.3-main.log -s -o -c config_file="/etc/postgresql/8.3/main/postgresql.conf" : Aucun fichier ou dossier de ce type ... failed!
failed!Pourtant comme indiqué plus haut les fichiers mentionnés dans la commande sont bel et bien présent sur mon système. J’ignore alors quel est le fichier manquant.
De plus la commande apt-get install postgresql-8.3, pour réinstaller postgresql en parallèle, me donne l’erreur suivante :
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Certains paquets ne peuvent être installés. Ceci peut signifier que vous avez demandé l'impossible, ou bien, si vous utilisez la distribution unstable, que certains paquets n'ont pas encore été créés ou ne sont pas sortis d'Incoming.
L'information suivante devrait vous aider à résoudre la situation :
Les paquets suivants contiennent des dépendances non satisfaites :
postgresql-8.3: Dépend: libkrb53 (>= 1.6.dfsg.2) mais ne sera pas installé
E: Paquets défectueuxMerci d’avance si vous avez une indication pour pouvoir relancer PostgreSQL 8.3.
Dernière modification par Philippe (01/09/2010 19:47:48)
Hors ligne
Bonjour,
Le problème de dépendance de PostgreSQL 8.3 risque d'être embêtant. Effectivement, il n'y a plus de libkrb53 en squeeze. Téléchargez la à la main à partir de cette page :
http://packages.debian.org/lenny/libkrb53 (prenez la version correspondant à votre processeur), et installez la avec dpkg -i
Une fois cela fait, retentez l'installation de postgresql 8.3
Marc.
Hors ligne
Hum.. disons qu'en fait lorsque je fait la commande apt-get install libkrb53 j'obtient la réponse suivante:
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
apache2-suexec-custom libgtk2.0-common pwgen libatk1.0-0 libio-compress-zlib-perl libcompress-raw-zlib-perl automake1.4 libxcb-render-util0 libmd5-perl mysql-client openssh-blacklist-extra libsensors3 db4.6-util libdjvulibre21
libcompress-zlib-perl djvulibre-desktop libilmbase6 ttf-dejavu-extra re2c sqlite clamav webmin-virtual-server webmin-virtualmin-awstats libmail-spf-perl clamav-freshclam awstats libcap1 libio-compress-base-perl libsocket6-perl
openssl-blacklist libxslt1.1 libserf-0-0 rdoc postgresql-doc-8.3 postgresql-doc-8.4 libsqlite0 libnet-xwhois-perl quota ri libcairo2 liberror-perl libnetaddr-ip-perl clamav-base libclamav6 spamassassin libpango1.0-common
libxcb-render0 hicolor-icon-theme libisccc50 libxxf86misc1 libapache2-mod-fcgid libmysqlclient15off libdirectfb-1.0-0 fontconfig spamc clamav-testfiles libmcrypt4 librecode0 libltdl3-dev libtidy-0.99-0 webmin-virtualmin-mailman
libjs-mootools libstartup-notification0 webmin-virtualmin-htpasswd liblwres50 libhunspell-1.2-0 libpango1.0-0 libt1-5 mailman libhal1 scponly webmin-security-updates mlock libgsf-1-common mysql-server irb libcroco3 libopenexr6
clamav-daemon clamav-docs libnet-ip-perl openssh-blacklist libthai0 dctrl-tools libio-socket-inet6-perl libnet-dns-perl libxtrap6 libsys-syslog-perl postgresql-doc libatk1.0-data procmail-wrapper webalizer webmin-virtual-server-theme
tcl8.4 webmin-virtualmin-dav psfontmgr libming0 libmozjs1d ttf-dejavu libmpfr1ldbl python-egenix-mxdatetime libvolume-id0 proftpd-basic postgresql-client-common libthai-data xorg-docs libnl1 apache2-doc python-egenix-mxtools
myspell-en-us libsysfs2 libtommath0 libmhash2 dbconfig-common usermin-virtual-server-theme libdigest-hmac-perl libisc52 dbus-x11 tinymce libgraphviz4 libdjvulibre-text proftpd-mod-mysql defoma libiodbc2 postgresql-common libnss3-1d
libavahi-core5 webmin-virtualmin-svn x-ttcidfont-conf libsys-hostname-long-perl libgsf-1-114 libltdl3 ri1.8 enscript libdigest-sha1-perl proftpd-mod-ldap
Veuillez utiliser « apt-get autoremove » pour les supprimer.
Paquets suggérés :
krb5-doc krb5-user
Les paquets suivants seront ENLEVÉS :
avahi-daemon bind9 bind9-host bind9utils curl cvsnt debian-goodies dnsutils dovecot-common dovecot-imapd dovecot-pop3d ghostscript gs-common iceweasel libapache2-mod-php5 libapache2-svn libbind9-60 libc-client2007e libcups2
libcupsimage2 libcurl3 libdbd-pg-perl libdns66 libgs8 libgsasl7 libgssapi-krb5-2 libgtk2.0-0 libgtk2.0-bin libisccfg60 libk5crypto3 libkrb5-3 libkrb5support0 libmagick10 libmailutils2 libneon27-gnutls libnss-mdns libpg-perl libpq5
librsvg2-2 libsvn1 libwmf0.2-7 mailutils mutt nfs-common openssh-client openssh-server php-auth php-auth-sasl php-mail-mime php-mail-mimedecode php-mdb2 php-mdb2-driver-mysql php-mdb2-driver-pgsql php-mdb2-driver-sqlite php-net-smtp
php-net-socket php-pear php5 php5-cgi php5-cli php5-curl php5-gd php5-idn php5-imagick php5-imap php5-ldap php5-mcrypt php5-memcache php5-ming php5-mysql php5-pgsql php5-pspell php5-recode php5-snmp php5-sqlite php5-suhosin php5-tidy
php5-xcache php5-xmlrpc php5-xsl phpmyadmin phppgadmin postgresql postgresql-8.4 postgresql-client-8.3 postgresql-client-8.4 proftpd-mod-pgsql python-subversion roundcube roundcube-core roundcube-sqlite sasl2-bin ssh subversion
sun-java6-plugin viewvc viewvc-query virtualmin-base xulrunner-1.9.1
Les NOUVEAUX paquets suivants seront installés :
libkrb53
0 mis à jour, 1 nouvellement installés, 99 à enlever et 1 non mis à jour.
Il est nécessaire de prendre 0o/482ko dans les archives.
Après cette opération, 207Mo d'espace disque seront libérés.
Souhaitez-vous continuer [O/n] ? n
Annulation.
Ce qui ne me donne certainement pas envie de continuer !!!
Ne risquerais-je pas d'avoir le même problème en faisant une installation manuelle ?
Hors ligne
Si. Je présume qu'il y a eu un changement dans la librairie kerberos: il veut désinstaller libkrb5, dans la liste des packages. Et les autres doivent en dépendre.
Dans ce cas, cela va être effectivement beaucoup plus compliqué: il n'y a effectivement plus de PostgreSQL 8.3 en squeeze.
Vous avez deux solutions :
- recompiler le package postgresql 8.3 sur la squeeze. C'est plus effrayant que difficile, en fait
- monter une lenny dans un bout d'arborescence, dans un chroot, avec debootstrap.
Je pencherais plutôt pour la première solution.
Marc.
Hors ligne
Bonsoir !
J’ai recompilé postgresql et j’ai en effet réussit à récupérer mes données. 
En faisait un dump j’ai réussit à les important dans mon cluster 8.4.
Par contre j’ai désormais deux problèmes :
* Que ce soit avec la 8.3 et que j’ai compilé (écoutant sur le port 5433), ou bien avec la 8.4 (reconfigurée pour écouter sur le port 5432), sous phppgadmin j’arrive bien à accéder aux données avec le compte postgres (j’ai temporairement désactivé la sécurité de phppgadmin) ; mais avec les autres utilisateurs j’ai l’erreur : « User does not have CONNECT privilege. » alors qu’il était tout à fait possible qu’un utilisateur accès à ses schémas. Cependant je constate que d’autres applications web utilisant mes comptes postgreSQL sont à nouveau fonctionne. Je me demande alors si ça ne viendrais pas de la configuration de pg_hba.conf ??
* La commade pg_dumpall ne fonctionne pas pour le server 8.4. En effet j’ai un avertissement comme quoi ma version de pg_dumpall est en 8.3.11 alors que l’host est en 8.4. Pourtant apt-get install postgresql-common ne me met rien à jour
Je pense que ce n’est plus grand-chose par rapport à ce que j’ai fait, mais j’aimerai pouvoir retrouver une installation la plus clean possible. Merci par avance
En tout cas, voici le détail de la procédure que j’ai effectué pour récupérer mes données :
Tout d’abord en tant que root :
apt-get build-dep postgresql-8.3Ensuite, en tant que compte ‘philippe’ :
tar -xzf postgresql-8.3.11.tar.gz
cd postgresql-8.3.11/
mkdir /home/philippe/postgres-install
./configure --prefix=/home/philippe/postgres-install --enable-integer-datetimes
make
make installPuis à nouveau en tant que root, récupération des données :
cp -R /var/lib/postgresql/8.3/main/ /home/philippe/postgres-install/data
chown -R philippe:philippe /home/philippe/postgres-install/Et en tant qu’utilisateur ‘philippe’ :
mkdir /home/philippe/postgres-install/var/
mkdir /home/philippe/postgres-install/etc/
cp /home/philippe/post.conf/postgresql.conf /home/philippe/postgres-install/etc/postgresql.conf
cp /home/philippe/post.conf/pg_hba.conf /home/philippe/postgres-install/etc/pg_hba.conf
cp /home/philippe/post.conf/pg_ident.conf /home/philippe/postgres-install/etc/pg_ident.conf
cp /home/philippe/post.conf/postmaster.opts /home/philippe/postgres-install/data/postmaster.optsOù les fichiers dans /home/philippe/post.conf/ dont des versions modifiés de /etc/postgresql/8.3/ et /var/lib/postgresql/8.3/main/postmaster.opts pour utiliser les dossiers dans /home/philippe/postgres-install/
J’ai aussi configurer pour lancer cette installation sur le port 5433
Enfin en tant que root, je refait un chown de mon dossier d’intall pour le compte postgres. Et en tant que postgres je lance la commande /home/philippe/postgres-install/bin/postgres "-D" "/home/philippe/postgres-install/data" "-c" "config_file=/home/philippe/postgres-install/etc/postgresql.conf"
Je fait mon dump avec pg_dumpall -h localhost -p 5433 -U postgres -f /home/philippe/backup/dump
Ensuite, j’ai reconfiguré ma 8.4 de Debian pour écouter sur le port par défaut 5432 et relancé le service. Et j’ai fait la commande psql < /home/philippe/backup/dump pour restaurer ma base.
Dernière modification par Philippe (02/09/2010 23:35:35)
Hors ligne
Mmm. Dommage de ne pas carrément être allé au bout de la démarche, et avoir récupéré le package source de postgresql 8.3 de la lenny. Il aurait été possible de le compiler pour squeeze.
Pour en revenir à cette histoire de connexion, je ne sais pas pourquoi, mais d'après le message d'erreur, les utilisateurs n'ont pas le privilège connect sur les bases sur lesquelles ils veulent se connecter. Par défaut ce privilège est donné à 'public', donc à tous les utilisateurs.
Donc pour réactiver ce privilège:
GRANT CONNECT ON DATABASE toto to titi;
titi pouvant être public si vous voulez revenir au paramétrage par défaut.
C'est évidemment à faire pour toutes les bases.
Marc.
Hors ligne
Que veux-tu dire ? Si je récupère les sources du dépot Debian alors je pourrait submitter un paquet pour squeeze ?
En fait mon problème d'utilisatuer a été réglé après redémarrage de la base.
Par contre, je ne sais pas quoi faire pour régler mon problème de pg_dumpall, actuellement il m'est impossible de procéder à un export 
Je sais pas pourquoi je n'ai pas la bonne version ? Et je pense pas que c'est le dépot qui n'est pas cohérent, je dois avoir un problème !
Hors ligne
En fait après avoir faire un apt-get install postgresql-client il semble que tout rentre dans l'ordre.
Puis-je désormais me permettre de supprimer les répertoires suivants ?
/usr/share/postgresql/8.3/
/var/lib/postgresql/8.3/
/etc/postgresql/8.3/
et le script /etc/init.d/postgresql-8.3 ?
Hors ligne
submitter, non. Mais fabriquer pour ton usage personnel oui.
Macroscopiquement, ce que ça donne :
mettre les sources de la lenny dans sources.list (la ligne en deb-src)
apt-get update
apt-get source postgresql-8.3
Ça détarre un paquet de trucs et de machins dans le répertoire courant
Ensuite, aller dans le sous répertoire créé, et lancer dpkg-buildpackage. Il est probable qu'il râle sur des problèmes de dépendance, puisque la libkrb a changé de nom. Si c'est la seule chose qui le chagrine, lancer dpkg-buildpackage -d
Et normalement ça compile. Si ça râle encore, il se peut que tu aies à aller modifier le fichier rules, et désactiver des options de configure pour être tranquille (par exemple, je présume que pour un simple dump, tu n'as pas besoin de kerberos ou de pl-python, ou de la doc )
Pour ce qui est du pg_dumpall, c'est quoi le problème exactement?
Marc.
Hors ligne
Si tu es sûr de ne plus avoir besoin d'eux, oui, évidemment.
Marc.
Hors ligne