Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 Re : Migration » migration Pgsql 8.3 en 8.4 » 28/05/2010 18:44:57
ç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
#2 Re : Migration » migration Pgsql 8.3 en 8.4 » 28/05/2010 11:14:43
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
#3 Re : Migration » migration Pgsql 8.3 en 8.4 » 28/05/2010 08:44:37
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 ??
#4 Re : Migration » migration Pgsql 8.3 en 8.4 » 26/05/2010 11:10:16
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 ?
#5 Re : Migration » migration Pgsql 8.3 en 8.4 » 26/05/2010 10:29:15
question stupide :
si je recopie ces fichiers dans leur équivalent 8.4 (Pg arrêté of course) je vais à la catastrophe au redémarrage ?
#6 Re : Migration » migration Pgsql 8.3 en 8.4 » 26/05/2010 09:36:50
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..
#7 Migration » migration Pgsql 8.3 en 8.4 » 23/05/2010 22:59:30
- YannT
- Réponses : 28
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
#8 Re : Général » problème de conversion de type » 15/01/2009 20:41:10
Merci,
En fait mes valeurs entières étaient le résultat de select count, et ce sont ces Select count que j'ai du caster :
select count(ouv1.idcat), round((cast(count(ouv1.idcat) as numeric(5,2))/
cast((select count(ouv2.idouv) from ouvrage ouv2) as numeric(5,2) )*100 ))||' %' as pourcent
from ouvrage ouv1
group by ouv1.idcat
order by count(ouv1.idcat) desc
count | pourcent
-------+----------
67 | 45 %
44 | 30 %
38 | 26 %
sans doute un peu lourdingue, mais je n'ai pas mieux
#9 Général » problème de conversion de type » 14/01/2009 18:06:22
- YannT
- Réponses : 3
Bonjour,
quelqu'un peut-il m'expliquer pourquoi un :
select cast (67/147 as numeric(5,5) )
me renvoie :
0.00000
au lieu du 0,45578 attendu ?
Postgres 8.3
Ubuntu 8.04
#10 Re : Général » Problème de mise à jour d'une ligne d'une table » 05/12/2008 18:16:16
C'est résolu
Le problème venait d'un trigger qui calcule la clef unique idouv et que j'avais (bêtement) laissé "before update"
en modifiant le trigger en "before insert" uniquement tout est revenu dans l'ordre
Merci à vous
#11 Général » Problème de mise à jour d'une ligne d'une table » 04/12/2008 20:49:32
- YannT
- Réponses : 3
bonjour,
lors d'une tentative d'update d'une ligne :
update ouvrage set titre_tome='tome 1' where idouv='LING1';
j'obtiens ce message d'erreur :
ERREUR: la valeur d'une clé dupliquée rompt la contrainte unique « ouvrage_pkey »
or un
select * from ouvrage where idouv = 'LING1';
m'affiche bien une seule ligne.
j'ai fait un analyze verbose ouvrage qui me signalait des lignes à supprimer
donc j'ai fait ensuite VACUUM FULL ouvrage
mais le problème subsiste
quelqu'un a une idée ?
#12 Général » mise à jour d'une colonne timestamp sur update de ligne » 08/11/2008 19:05:18
- YannT
- Réponses : 1
Bonjour,
Merci pour la réponse à ma précédente question.
Je cherche maintenant à mettre à jour la colonne timestanp d'une ligne avec la date et l'heure courante à chaque fois que cette ligne est mise à jour.
Un trigger se déclencherait sans fin donc y a t'il un processus ou une particularité Postgres me permettant d'effectuer cela ?
Merci d'avance
#13 Général » Syntaxe pour créer une fonction contenant des caractères réservés » 06/11/2008 23:22:18
- YannT
- Réponses : 1
Bonjour,
Commençant tout juste à me former sur Postgres je rencontre un problème de syntaxe pour créer une fonction
Le but de la fonction est de compter le nombre de lignes commençant par une chaîne et de renvoyer le résultat :
voici la syntaxe que j'ai utilisé :
CREATE OR REPLACE FUNCTION nouvelindex(text)
RETURNS bigint AS
$BODY$
SELECT COUNT(*) FROM auteur WHERE idaut LIKE '$1%'
$BODY$
LANGUAGE 'sql';
Cette fonction ne fonctionne pas et renvoie toujours 0 :
select nouvelindex('STEI');
nouvelindex
-------------
0
(1 ligne)
alors que lancé à la main j'obtiens bien le bon résultat :
select count(*) from auteur where idaut like 'STEI%';
count
-------
1
(1 ligne)
Je suppose qu'il s'agit d'échapper les ' ou le % mais je n'y arrive pas
quelqu'un a une idée ?
Merci d'avance
Pages : 1