Vous n'êtes pas identifié(e).

#51 Re : Général » postgres schema denied for relation nomde la table » 28/04/2010 14:25:32

Mich30,

Il suffit de lire la documentation de GRANT, c'est écrit dedans. Noir sur blanc.

http://docs.postgresqlfr.org/8.4/sql-grant.html

Bonne lecture,

#52 Re : PL/pgSQL » Fonctionnement des curseurs sous PL/pgSQL » 01/02/2010 15:14:24

Bonjour Sophonie,

Tout d'abord, si je vous ai répondu, ce n'était pas pour faire de la pub à ma société, mais juste parce que j'avais trouvé, ce Samedi matin, la réponse à vos tourments :-)

Cependant, votre réponse me flatte.

Pour ce qui est des exercices pratiques sur PL/pgSQL, je vais me renseigner pour savoir ce que nous pouvons faire, dans la mesure où nous avons effectivement un cursus de formation sur ce langage, avec des TPs justement.

Bonne journée,

#53 Re : PL/pgSQL » Fonctionnement des curseurs sous PL/pgSQL » 30/01/2010 11:24:21

Bonjour,

J'imagine que tout cela est à but pédagogique n'est-ce pas? Car il y a des façons plus simples de peupler multiplication... Bref.

Votre problème est ici :

SELECT num2 FROM table2 WHERE num2 = val.num1

Si table2 contient des multiples de 12, l'égalité num2= val.num1 sera vraie tous les 12 tuples.

C'est à dire qu'entre 0 et 100, cette égalité sera vraie 8 fois.

Le reste du temps, c'est null. Et null x valeur = null. Ce qui explique vos "blancs" dans la table, qui sont en fait des null.

Je vous laisse corriger? smile

Bon week-end,

#54 Re : Général » postgresql et mysql » 30/01/2010 11:11:05

Bonjour imenisg,

Je ne connais pas de projet qui permette de convertir directement des fichiers de données MySQL.

Par contre, je vous encourage à utiliser mysql2pgsql, qui permet de convertir très facilement et très efficacement un dump MySQL en dump PostgreSQL.

Voici la page du projet  :  http://pgfoundry.org/projects/mysql2pgsql/

Cordialement,

#55 Re : Réplication » Slony/PG8.4 sous Windows » 23/12/2009 12:13:24

Bonjour,

Vous pouvez utiliser la version 1.2.20 de Slony-I

http://www.slony.info/
http://main.slony.info/downloads/1.2/so … 20.tar.bz2

Pour Debian, la version 1.2.20 a été acceptée hier par Peter Eisentraut:
http://packages.qa.debian.org/s/slony1/ … 4639Z.html

Ça ne devrait donc pas tarder à tomber en unstable, étant donné qu'on trouve le paquet sur
http://incoming.debian.org/   (ok, en cherchant bien, je vous l'accorde : cherchez le mot clé "postgresql" avec l'outil de recherche de votre navigateur).

Bonne journée,

#56 Re : Général » pgpool-II, traduction » 23/12/2009 11:34:09

Ah...

Bin pas la peine de chercher plus loin pour votre "lettre nigerianne". Si vous avez mis, ne serait-ce qu'une fois, votre email de cette façon en clair dans le forum, nombre de robots à spam vont faire le lien entre ce site web, votre login et votre e-mail...

Du coup, vous recevez des spams "personnalisés".

Bonne journée,

#57 Re : Site PostgreSQL.fr » lettre nigerianne » 23/12/2009 11:32:25

Hum,

C'est curieux... Je vais demander aux admins du forum (gleu en particulier) s'il y a une possibilité de récupérer vos e-mails d'une façon ou d'une autre.... Normalement vos e-mails ne sont pas visibles, mais sait-on jamais?

Merci en tout cas d'avoir porté ce cas à notre connaissance.

Bonne journée,

#58 Re : Général » Intersection de 2 path (chemins ouverts) » 23/12/2009 11:30:25

Bonjour,

À ma connaissance PostgreSQL "tout seul" ne sait retourner qu'une chose sur la question: savoir s'il y a une intersection entre les deux paths et dans votre cas c'est "vrai":

select '((1,1),(2,2),(3,0),(5,5),(-3,10))'::path ?#
       '((0,1),(1,0),(4,1),(5,2),(5,3))'::path as intersection;
intersection
--------------
  t
(1 ligne)

Si vous voulez avoir l'aire de l'intersection, je ne vois pas d'autre solution que d'utiliser PostGIS, avec sa fonction intersection(geometry,geometry), comme expliqué sur la page suivante:

http://www.postgis.fr/node/221

Bon courage,

#59 Re : Migration » Changement de bases de données depuis Mysql » 02/12/2009 13:10:21

Bonjour,

S'il s'agit de migrer de MySQL à PostgreSQL c'est assez facile à faire. Pour ma part j'utilise mysql2pgsql, c'est un outil libre que vous pouvez vous procurer sur pgfoundry à cette adresse:

http://pgfoundry.org/projects/mysql2pgsql/

Bonne journée,

#60 Re : Général » Pb urgent : autovacuum démarre malgrés le postgresql.conf » 30/11/2009 18:27:44

Bonjour,

Je vous recommande tout d'abord une relecture très attentive du chapitre
" 23.1.4. Éviter les cycles des identifiants de transactions" sur la page:
http://docs.postgresqlfr.org/8.4/mainte … -vacuuming

Ce qui vous arrive, c'est que vous approchez de la limite fatidique où les identifiants de transaction vont être recyclés. Le VACUUM est donc inévitable et vous *devez* le faire.

Comme il est dit dans ces pages, vous devrez ARRETER votre serveur, puis passer en mode mono-utilisateur en lançant à la main un processus "postgres", comme il c'est indiqué sur cette page (cherchez le mot-clé "--single"):
http://docs.postgresqlfr.org/8.4/app-postgres.html

Maintenant, 2 remarques complémentaires:

* autovacuum = on commenté ne suffit pas pour le désactiver ! Il est en effet activé par défaut dans votre versions)

* vous dites faire une maintenance manuelle de la base (pas d'autovacuum): cette façon de procéder a manifestement ses limites à présent, puisque vous arrivez en recyclage des ID de transaction :-/ Il faudra dont veiller à augmenter la fréquence des VACUUM, ou alors, ce qui est plus sage, d'opter pour un autovacuum activé.

En tout cas, tant que le VACUUM ne sera pas fait en mode single user (arrêt des applications à faire donc!), vous ne pourrez plus rien faire sur cette base, par mesure de sécurité (cf le chapitre 23.1.4 que vous allez donc lire en entier!).

Bon courage pour la suite,

#61 Re : Optimisation » Logiciels / scripts pour supervision et optimisation » 30/11/2009 17:00:05

check_postgres(.pl) yota ;-)

Et oui, c'est vraiment ce qu'il te faut je pense.

À bientôt aux détours d'un stand (afpy ou postgresqlfr :-)

++

#62 Re : Général » ./psql –d template1 –f /usr/local/pgsql/share/contrib/postgis.sql bad » 27/10/2009 10:58:18

Bonjour,

Pouvez-vous essayer de créer une base à part et d'y installer postgis?
/usr/local/pgsql/bin/createdb mabase
/usr/local/pgsql/bin/psql –d mabase –f /usr/local/pgsql/share/contrib/postgis.sql

Aussi, merci de nous donner les éventuelles erreurs contenues dans le postgresql.log

(pour savoir où est ce fichier:
/usr/local/pgsql/bin/psql -c "show log_directory" -d template1

et son nom:
/usr/local/pgsql/bin/psql -c "show log_filename" -d template1
)

Enfin, pensez à ajouter le chemin des binaires de PostgreSQL dans votre $PATH. Cela vous évitera de taper le fastidieux chemin "/usr/local/pgsql/bin/" devant vos commandes.

export PATH=$PATH:/usr/local/pgsql/bin/

#64 Re : Général » inserer une image ? » 27/01/2009 10:10:57

Bonjour,

Dans le code de la création de la table, vous devez remplacer le type de données "bytea" par "oid", comme indiqué dans la doc:
http://docs.postgresqlfr.org/8.3/lo-funcs.html

Bonne journée,

#65 Re : Général » PostgreSQL et Openldap » 26/01/2009 18:42:42

Bonjour arlequ1,

Vous trouverez quelques documents utiles je pense sur le site de Gilles Darold, du groupe Samse (voir http://www.samse.fr/GPL/), plus précisément dans la partie "Conferences / documentation", ces deux documents devraient vous intéresser:

* HOWTO OpenLDAP / PostgreSQL : vieux document, mais il explique bien les choses. Attention, il n'est désormais plus nécessaire de patcher PostgreSQL comme indiqué dans ce doc: http://www.samse.fr/GPL/ldap_pg/HOWTO/

* "Implementation d'un annuaire LDAP au sein du Groupe SAMSE": http://www.samse.fr/GPL/ldap_samse/index.html

En espérant que ces deux documents vous permettront d'avancer.

N'hésitez pas à contacter Gilles en cas de question technique, le connaissant, je pense qu'il se fera un plaisir de vous répondre.

Cordialement,

#67 Re : Général » Problème avec pg_dump sur un bytea » 21/11/2008 10:00:30

De rien!

Bien content que vous ayez pu résoudre votre problème...

Bonne journée,

#68 Re : Général » ETL gratuit pour fichiers utilisant postgreSQL » 05/11/2008 09:48:48

Salut Benoît!

Tout d'abord, merci pour ton travail :-) Par contre, ce matin, j'ai voulu essayer ta dernière version, et dans le ZIP, on ne trouve qu'un .EXE windows :-(

Vu que c'est du Java, j'imagine que tu peux distribuer ça comme un .jar qu'on n'aurait qu'à installer non?

Peux-tu m'expliquer comment je peux installer Benetl sous Linux (sans Wine bien sûr) ?

Par avance, merci.

PS: la question sur la licence m'intéresse moi aussi

#69 Re : Réplication » les WAL » 21/10/2008 10:14:29

Hola Luis,

Supongo que eres espanol o que por lo menos es tu idioma principal. Tienes ayuda en PostgreSQL tambien por varios medios:

* la lista: http://mail.postgresql.org/mj/mj_wwwusr … l-es-ayuda

* el web: http://www.postgresql.cl/ por ejemplo, es la communidad Chilena

* el IRC : irc.freenode.net, #postgresql-es donde estoy, con otros, a diaro

Attentamente,

#70 Re : Général » Problème avec pg_dump sur un bytea » 19/10/2008 01:03:55

Ok..

La conclusion de l'histoire est double:
1. Tom Lane est vraiment trop fort
2. On fait un bug report sur pgsql-hackers, en se servant de votre exemple détaillée et précis. On verra bien ce que les hackers en pensent...

Merci pour la masse d'informations envoyées, je pense qu'on devrait pouvoir transformer tout cela en bug report.

Tenez nous au courant ça marche/ça marche pas.

#71 Re : Général » erreur lors de l'import de données » 06/10/2008 17:35:16

Bonjour,

Pourquoi vous ne faites pas en sorte de changer l'encodage de ce fichier? Sous linux, vous pourriez utiliser iconv pour cela. Sous windows, ça doit exister aussi...

Cordialement,

#72 Re : Général » Exporter des données » 06/10/2008 17:33:13

Bonjour elfredo,

La solution la plus simple est de faire un dump de votre base actuelle pour la restaurer ailleurs. Sur cette base-là vous pourrez alors faire vos modifications de données sans soucis, si vous avez des contraintes ou autres, PostgreSQL saura vous le notifier, et vous ferez les choses "dans l'ordre".

Ensuite, soit vous laissez cela en l'état (si c'est bien une copie de la base d'origine, mais avec des données modifiées, que vous vouliez), soit vous exportez les données de cette base sous la forme d'INSERT, c'est un peu barbare, mais ça marche (si vous vouliez insérer des données dans une autre base...).

En espérant avoir été d'une aide quelconque,

#73 Re : Général » Problème avec pg_dump sur un bytea » 26/09/2008 17:16:34

Re,

J'ai soumis votre cas à la communauté, voici les bonnes idées qui en ressortent:

- cela semble être un problème avec la partie CLIENTE de votre installation et pas le serveur, puisque le COPY marche et que COPY (de la façon dont vous le faites: COPY table TO file) est une commande serveur.

- essayez de faire un \copy dans le client psql:

  \copy table [ ( liste_colonne ) ] { from | to } { nomfichier | stdin | stdout | pstdin | pstdout } [ with ] [ oids ] [ delimiter [ as ] 'caractère' ] [ null [ as ] 'chaîne' ] [ csv [ quote [ as ] 'caractère' ] [ escape [ as ] 'caractère' ] [ force quote liste_colonne ] [ force not null liste_colonne ] ]

à mon avis, ce \copy echouera comme le backup.

Une solution consisterait alors à utiliser un pg_dump dans une version plus récente, pourquoi pas 8.2... Il vous faudra alors installer (ou compiler si ça n'est pas disponible en paquet pour votre Red Hat) un paquet "postgresql-client" plus récent.

À mon humble avis, et pour éviter tout problème sur ce serveur (de production si j'ai bien compris), je vous engage à installer ce client PostgreSQL sur un autre serveur et à dumper depuis ce dernier.

Tenez-nous au courant de ces quelques tests.

Merci !

#74 Re : Général » Problème avec pg_dump sur un bytea » 26/09/2008 17:00:46

Ok.

Merci pour ce retour... Attention à l'option -Z 9 ... Cela signifie que vous demandez une compression maximale. Je pense que cela peut expliquer une bonne partie du temps et de la charge CPU. Pourquoi compresser autant? Pourriez vous essayer avec une compression minimale? (-Z 1 ?) voire sans compression (-Z 0) (mais attention à l'espace disque!)...

Cordialement,

#75 Re : Général » Problème avec pg_dump sur un bytea » 25/09/2008 16:01:39

Bonjour,

Je viens de regarder un peu le code de pgdump.c et j'ai quelques questions.. Bien sûr, vous utilisez une vieille version de PostgreSQL, mais ça n'explique pas ce comportement, du moins je le pense.

Je me demande s'il n'y a pas une corruption de données. Est-ce qu'un "SELECT * FROM wct_binary" aboutit sans erreur(s)? Si oui, quelles sont-elles?

Enfin, pourriez-vous augmenter le niveau de messages renvoyés par PostgreSQL? Sauvegardez votre postgresql.conf et changez les paramètres log_... pour mettre des valeurs à DEBUG1 par exemple...

En espérant que vous puissiez nous poster plus de détails,

Cordialement,

Pied de page des forums

Propulsé par FluxBB