Les nouveautés des produits dérivés
Offres d'emplois autour de PostgreSQL en janvier
PostgreSQL Local
PostgreSQL dans les média
PostgreSQL Weekly News / les nouvelles hebdomadaires vous sont offertes cette semaine par David Fetter. Traduction par l'équipe PostgreSQLFr sous licence CC BY-NC-SA.
Proposez vos articles ou annonces avant dimanche 15:00 (heure du Pacifique). Merci de les envoyer en anglais à david (a) fetter.org, en allemand à pwn (a) pgug.de, en italien à pwn (a) itpug.org et en espagnol à pwn (a) arpug.com.ar.
(lien vers l'article original)
Correctifs appliqués
Robert Haas a poussé :
Peter Eisentraut a poussé :
Alvaro Herrera a poussé :
Magnus Hagander a poussé :
Heikki Linnakangas a poussé :
Bruce Momjian a poussé :
Correctifs rejetés (à ce jour)
Correctifs en attente
Visiblement nous avons visé juste ! En choisissant la Réplication comme thème de la prochaine Session PostgreSQL nous savions que le public répondrait nombreux mais nous n'avions pas prévu un tel engouement... Le conférence qui se tiendra le 2 février à Paris affiche quasiment complet ! Au moment ou j'écris ces lignes , il ne reste plus qu'une poignée de places disponibles. Si vous êtes intéressé par les problématiques de Haute-Disponibité sous PostgreSQL, je vous encourage à vous inscrire le plus rapidement possible à cette adresse :
http://www.postgresql-sessions.org/3/registration_form
Pour rappel, la session se tiendra de 9h30 à 17h30 au Comptoir Général situé 80 quai de Jemmapes à Paris ( http://osm.org/go/0BPIqc7Q )
Parmi les orateurs, nous aurons la chance de compter :
Le programme complet est disponible ici : http://www.postgresql-sessions.org/3/
Rendez-vous le 2 février à Paris !
Le FOSDEM 2012 se tiendra du 4 au 5 février à Bruxelles. C'est un rendez-vous important de la communauté européenne de PostgreSQL et comme d'habitude vous retrouverez pas mal de francophones derrière le stand de l'association PostgreSQL Europe !
Rappelons que le FOSDEM est un événement gratuit et sans inscriptions. Plus d'informations par ici : http://fosdem.org/2012/
Cette année encore, il y a une journée entière de conférences (en anglais) dédiée à PostgreSQL :
http://fosdem.org/2012/schedule/track/postgresql_devroom
Rendez-vous à Bruxelles le 4-5 février !
La Commitfest n°4 est lancée. Commencez à relire ces patchs ! https://commitfest.postgresql.org/action/commitfest_view?id=13
La PGCon 2012 sera tenue à l'Université d'Ottawa, les 17 et 18 mai 2012. Elle sera précédée par deux jours de tutoriels les 15 & 16 mai 2012 : http://www.pgcon.org/2012/
Offres d'emplois autour de PostgreSQL en janvier
PostgreSQL Local
PostgreSQL dans les média
PostgreSQL Weekly News / les nouvelles hebdomadaires vous sont offertes cette semaine par David Fetter. Traduction par l'équipe PostgreSQLFr sous licence CC BY-NC-SA.
Proposez vos articles ou annonces avant dimanche 15:00 (heure du Pacifique). Merci de les envoyer en anglais à david (a) fetter.org, en allemand à pwn (a) pgug.de, en italien à pwn (a) itpug.org et en espagnol à pwn (a) arpug.com.ar.
(lien vers l'article original)
Correctifs appliqués
Magnus Hagander a poussé :
Robert Haas a poussé :
Peter Eisentraut a poussé :
Tom Lane a poussé :
Heikki Linnakangas a poussé :
Alvaro Herrera a poussé :
Simon Riggs a poussé :
Andrew Dunstan a poussé :
Correctifs rejetés (à ce jour)
Correctifs en attente
Les nouveautés des produits dérivés
Offres d'emplois autour de PostgreSQL en janvier
PostgreSQL Local
PostgreSQL dans les média
PostgreSQL Weekly News / les nouvelles hebdomadaires vous sont offertes cette semaine par David Fetter. Traduction par l'équipe PostgreSQLFr sous licence CC BY-NC-SA.
Proposez vos articles ou annonces avant dimanche 15:00 (heure du Pacifique). Merci de les envoyer en anglais à david (a) fetter.org, en allemand à pwn (a) pgug.de, en italien à pwn (a) itpug.org et en espagnol à pwn (a) arpug.com.ar.
(lien vers l'article original)
Revues de code
Correctifs appliqués
Bruce Momjian a poussé :
Tom Lane a poussé :
Peter Eisentraut a poussé :
Andrew Dunstan a poussé :
Michael Meskes a poussé :
Robert Haas a poussé :
Correctifs rejetés (à ce jour)
Correctifs en attente
Bonne Année de la part des Nouvelles Hebdomadaires de PostgreSQL !
Les nouveautés des produits dérivés
PostgreSQL Local
PostgreSQL dans les média
PostgreSQL Weekly News / les nouvelles hebdomadaires vous sont offertes cette semaine par David Fetter. Traduction par l'équipe PostgreSQLFr sous licence CC BY-NC-SA.
Proposez vos articles ou annonces avant dimanche 15:00 (heure du Pacifique). Merci de les envoyer en anglais à david (a) fetter.org, en allemand à pwn (a) pgug.de, en italien à pwn (a) itpug.org et en espagnol à pwn (a) arpug.com.ar.
(lien vers l'article original)
Revues de code
Correctifs appliqués
Alvaro Herrera a poussé :
Peter Eisentraut a poussé :
Tom Lane a poussé :
Bruce Momjian a poussé :
Simon Riggs a poussé :
Correctifs rejetés (à ce jour)
Correctifs en attente
Dalibo organise le jeudi 2 février 2012 à Paris une rencontre internationale consacrée au Système de Gestion de Bases de Données PostgreSQL.
Le thème de cette journée sera la réplication, avec des invités de marques notamment :
* Mickaël Paquier (Japon), Développeur de Postgres-XC * Simon Riggs (Angleterre), Contibuteur majeur de PostgreSQL * Ludovic Levesque (France), Directeur Technique de Fotolia
L'objectif de cette conférence est de faire un tour d'horizon des solutions de Haute-disponibilités : PGXC, Slony, Londiste et avec bien sûr un accent particulier la réplication interne avec le Hot Standby / Streaming Replication !
Retrouvez le programme complet sur le site de l'évènement : http://www.postgresql-sessions.org/...
La session se tiendra de 9h30 à 17h30 au Comptoir Général situé 80 quai de Jemmapes à Paris ( http://osm.org/go/0BPIqc7Q )
Cet événement est gratuit et ouvert à tous, dans la limite des places disponibles.
Les inscriptions se font via la page ci-dessous : http://www.postgresql-sessions.org/...
Pour toute précision, n'hésitez pas à envoyer un message à contact@postgresql-sessions.org
Bonne journée et Rendez-vous le 2 février juin à Paris !
À propos des Sessions PostgreSQL : Les sessions PostgreSQL sont avant tout des moments pour découvrir et rencontrer la communauté PostgreSQL. Chaque session est une journée composée de conférences et d'ateliers, organisée autour d'un thème précis et d'un invité de marque.
» site web : http://www.postgresql-sessions.org/
À propos de Dalibo : Spécialiste français de PostgreSQL, Dalibo met à la disposition de ses clients son savoir-faire dans le domaine des bases de données et propose des services de conseil, de formation et de support aux entreprises et aux institutionnels.
» site web : http://www.dalibo.com/
HTSQL 2.2, un langage de haut-niveau pour les bases de données relationnelles : http://htsql.org
psycopg2 2.4.3, un connecteur Python pour PostgreSQL : http://initd.org/psycopg/articles/2011/12/12/psycopg-243-released/
Offres d'emplois autour de PostgreSQL en décembre
PostgreSQL Local
PostgreSQL dans les média
PostgreSQL Weekly News / les nouvelles hebdomadaires vous sont offertes cette semaine par David Fetter. Traduction par l'équipe PostgreSQLFr sous licence CC BY-NC-SA.
Proposez vos articles ou annonces avant dimanche 15:00 (heure du Pacifique). Merci de les envoyer en anglais à david (a) fetter.org, en allemand à pwn (a) pgug.de, en italien à pwn (a) itpug.org et en espagnol à pwn (a) arpug.com.ar.
(lien vers l'article original)
Revues de code
Correctifs appliqués
Tom Lane a poussé :
Alvaro Herrera a poussé :
Peter Eisentraut a poussé :
Robert Haas a poussé :
Correctifs rejetés (à ce jour)
Correctifs en attente
Les nouveautés des produits dérivés
Offres d'emplois autour de PostgreSQL en décembre
PostgreSQL Local
PostgreSQL dans les média
PostgreSQL Weekly News / les nouvelles hebdomadaires vous sont offertes cette semaine par David Fetter. Traduction par l'équipe PostgreSQLFr sous licence CC BY-NC-SA.
Proposez vos articles ou annonces avant dimanche 15:00 (heure du Pacifique). Merci de les envoyer en anglais à david (a) fetter.org, en allemand à pwn (a) pgug.de, en italien à pwn (a) itpug.org et en espagnol à pwn (a) arpug.com.ar.
(lien vers l'article original)
Revues de code
Correctifs appliqués
Heikki Linnakangas a poussé :
Tom Lane a poussé :
Andrew Dunstan a poussé :
Peter Eisentraut a poussé :
Robert Haas a poussé :
Bruce Momjian a poussé :
Michael Meskes a poussé :
Correctifs rejetés (à ce jour)
Correctifs en attente
Nouvelles versions correctives 9.1.2, 9.0.6, 8.4.10, 8.3.17 and 8.2.23. Il s'agit de la dernière publication officielle de la série 8.2. Si vous utilisez la réplication intégrée, il est conseillé de mettre à jour dès que possible : http://www.postgresql.org/about/news/1366/
FOSDEM 2012 - Devroom PostgreSQL : l'appel à conférenciers est lancé (date limite de dépôt : 20 décembre 2011) : https://www.postgresql.eu/events/callforpapers/fosdem2012/
Les nouveautés des produits dérivés
Offres d'emplois autour de PostgreSQL en décembre
PostgreSQL Local
PostgreSQL dans les média
PostgreSQL Weekly News / les nouvelles hebdomadaires vous sont offertes cette semaine par David Fetter. Traduction par l'équipe PostgreSQLFr sous licence CC BY-NC-SA.
Proposez vos articles ou annonces avant dimanche 15:00 (heure du Pacifique). Merci de les envoyer en anglais à david (a) fetter.org, en allemand à pwn (a) pgug.de, en italien à pwn (a) itpug.org et en espagnol à pwn (a) arpug.com.ar.
(lien vers l'article original)
Patches
La section des patchs ne sera pas publiée cette semaine. Si vous souhaitez son retour, veuillez contacter david AT fetter DOT org, en particulier si vous avez des ressources -du temps par exemple- à donner au projet.
Un article récent en anglais propose dix bonnes raisons de choisir PostgreSQL plutôt que SQL Server dans le cadre d’un nouveau projet, ce qui nous offre une belle occasion de revenir sur notre publication précédente qui ciblait la migration vers PostgreSQL. Nous pouvons donc cette fois nous intéresser de plus prêt aux particularités de PostgreSQL !
La dizaine de points choisis par Jeremiah Peschka dans l’article précédent s’éloigne parfois de la liste que j’aurais moi-même établie, aussi vais-je éviter de vous faire une traduction simple du contenu anglais mentionné. Plusieurs points méritent tout de même d’être mentionnés ici.
PostgreSQL stabilise et distribue une nouvelle version majeure de sa base de données chaque année. Le cycle de développement actuel (que nous connaissons bien ici, pour y participer) est composé de deux grandes étapes, six mois de développement suivis de six mois de relectures, tests, correctifs, polissages et améliorations de la documentation.
Cela permet d’obtenir de très bonnes versions point zéro autour du mois de septembre chaque année. Cela n’a pas toujours été le cas dans la gestion du projet PostgreSQL, mais ce modèle a été mis en place de manière professionnelle sur plusieurs années afin de pouvoir mieux accepter les améliorations apportées par plus de deux cents développeurs en moyenne.
Bien sûr, très peu de projets industriels peuvent se permettre de revoir leur architecture, leurs procédures et leur intégration SQL chaque année, et même dans le milieu très dynamique des services web cela n’arrive quasiment pas.Aussi les versions de PostgreSQL sont-elles maintenues pendant au moins cinq ans, les versions courantes de PostgreSQL sont donc au nombre de 5 à 7 selon les moments de l’année.
L’avantage n’est donc pas de pouvoir mettre à jour chaque année, mais bien de pouvoir en toute sérénité choisir la date de mise à jour de la version de PostgreSQL selon son propre calendrier de maintenance et d’évolutions avec la garantie de pouvoir à tout moment choisir une nouvelle version vieille au maximum d’un an.
Il existe ensuite de nombreux points techniques donnant un avantage très net à PostgreSQL, soit qu’il s’agisse d’innovations technologiques issues de la recherche, telles les « Serializable snapshot isolation » (ou SSI), ou bien la réplication synchrone contrôlable pour chaque transaction ; ou bien qu’il s’agisse de supports avancés aux développeurs, telles les recherches des plus proches voisins via un parcours d’index, les requêtes avancées en écriture (comparable au pipe sous unix, mais avec des ordres de lecture ou d’écriture SQL), ou bien le support avancé des types de données souvent utilisés.
Ces capacités avancées, cette souplesse d’utilisation et de paramétrage dynamique, associés à des caractéristiques de performance époustouflantes (dans la plupart des usages, dont très certainement le vôtre), la qualité de sa documentation, tout cela donne un avantage crucial à PostgreSQL : une réduction imbattable des coûts de développement et de maintenance de vos logiciels.
Vos développeurs peuvent écrire des requêtes complexes avec la garantie d’obtenir le bon résultat même dans une utilisation concurrente, faire des calculs de dates dans des timezones différentes et au milieu du changement d’heure (tous les mois ne font pas le même nombre de jours, tous les jours ne font pas 24 heures non plus, PostgreSQL le sait), exprimer des contraintes avancées (le même client ne doit pas réserver deux voitures différentes dans le même créneau horaire) qui doivent fonctionner systématiquement et sans verrous, etc.
Bénéficier de PostgreSQL pour résoudre cet ensemble de problème permet de ne pas avoir à les résoudre à nouveau dans votre application (quel jour serons-nous dans trois mois ? SELECT to_char(date 'today' + 3 * interval '1 month', 'Day'); est sûrement plus facile à utiliser que n’importe quel autre code, les développeurs lisant cela seront sûrement d’accord). Le temps passé à exploiter la documentation de PostgreSQL est un investissement facile à réutiliser et à rentabiliser, et c’est du temps de gagné dans le développement de ce qui fait la valeur ajoutée de votre application.
La raison pour laquelle nous aimons tant vanter les qualités techniques de PostgreSQL est simple. Il s’agit là d’un formidable levier vous permettant de produire des application meilleures car plus simple à développer, à faire évoluer, à maintenir, déployer et administrer.
Bien évidemment, tout cela sans s’acquitter de coûts de licence appliqués par serveur ou qui dépendent de la capacité et du nombre d’installations dont vous avez besoin pour déployer une architecture. Mettre en place une solution tolérante aux pannes, de la répartition de charge pour vos rapports hebdomadaires, des instances de tests ou d’exports de données devient une décision plus facile à prendre car elle ne dépend pas des coûts de licence.
Il reste à former une équipe compétente, ce qui à mon sens est une bien meilleure utilisation de votre budget, et ce qui bien souvent représente un coût moins élevé que les licences dépensées en pure perte… dès lors que vous pouvez obtenir le même service à moindre coût. Nous pouvons vous aider à déterminer si PostgreSQL est le moteur de bases de données le mieux adapté à votre projet.
Pour connaitre la taille d'un base de données il faut utiliser la fonction pg_database_size
production=# select pg_database_size('production');
pg_database_size
------------------
513343780
(1 ligne)
Cette taille est donnée en octets, pour avoir une meilleur représentation en Méga ou Giga, il faut utiliser la fonction pg_size_pretty
production=# select pg_size_pretty(pg_database_size('production'));
pg_size_pretty
----------------
490 MB
(1 ligne)
Ensuite si l'on souhaite connaître la taille d'un table il faut utiliser la fonction pg_relation_size.
production=# select pg_size_pretty(pg_relation_size('res_partner'));
pg_size_pretty
----------------
152 kB
(1 ligne)
Si l'on souhaite également avoir la place prise par les indexes, il faut utiliser la fonction pg_total_relation_size
production=# select pg_size_pretty(pg_total_relation_size('res_partner'));
pg_size_pretty
----------------
528 kB
(1 ligne)
Contrairement à mon habitude, les manuels français de PostgreSQL n'ont été mis à jour que maintenant, soit cinq jours après la sortie des versions. Pour me faire pardonner, j'ai enfin corrigé le problème de la recherche dans la documentation de la version 9.1 (merci à Thomas pour l'info).
J'allais oublier... la documentation de la 8.2 n'a pas disparu. Elle est juste partie rejoindre les documentations des versions obsolètes.
Bonjour,
Le PostgreSQL Global Development Group (PGDG) a publié lundi 5 décembre des mises à jour sur toutes les branches actives du SGBD PostgreSQL, c'est à dire les versions 9.1.2, 9.0.6, 8.4.10, 8.3.17 and 8.2.23.
Les utilisateurs des fonctionnalités concernées par ces mises à jours, notamment la réplication binaire, doivent mettre à jours leurs instances PostgreSQL dès que possible.
Ceci est également la dernière mise à jour de PostgreSQL 8.2, qui est désormais en fin de vie (en anglais : "End-Of-Life" ou "EOL"). Les utilisateurs de la version 8.2 doivent planifier une montée de version de leurs instances PostgreSQL et migrer vers la version 8.3 ou supérieure dans les prochains mois. Pour plus d'information, consulter la Politique de support des Versions :
http://wiki.postgresql.org/wiki/Pos...
Les fonctionnalités affectées par cette mise à jour sont notamment : la réplication binaire et le Hot Standby, les indexes GIN, l'extension citext, le tri dans les fonctions de fenêtrage, l'intégrité référentielle par les clés étrangères, le PL/perl, et la gestion des extensions en général... Les utilisateurs de cette fonctionanlités doivent appliquées cette mise à jour sur le champ.
Cette publication contient 52 corrections pour la version 9.1, et un nombre inférieur de corrections pour les versions plus anciennes, notamment :
Les modifications marquées avec une étoile entre crochets (*) nécessitent des étapes supplémentaires, après mise à jour, pour corriger les problèmes décrits. Voir les notes de versions de chaque branche pour une liste complète des modifications avec des détails sur les correctifs et les étapes à suivre.
Comme pour les autres versions mineures, les utilisateurs ne doivent pas nécessairement sauvegarder puis recharger leur base de données pour mettre à jour. Arrêtez PostgreSQL, mettez à jour les binaires et relancez PostgreSQL.
Téléchargez les nouvelles versions maintenant sur :
Code source:
Paquets binaires:
La version originale de ce message est disponible ici : http://www.postgresql.org/about/new...
J'ai commencé à développer sous PostgreSQL assez récemment après une longue expérience sous Oracle. La documentation générale de PostgreSQL est excellente, et très riche, mais j'avais besoin d'un document plus léger expliquant la procédure d'installation sur différents systèmes et comment démarrer (créer un cluster, configurer les connexions), ainsi que des informations sur ce qu'on pouvait faire avec PostgreSQL. Je ne l'ai pas trouvé. Après quelques mois d'utilisation, je me suis rendu compte que les problèmes des débutants étaient toujours les mêmes. Ainsi, j'ai compilé mes notes des débuts et ce que j'ai appris depuis dans ce document. Voici le résultat, en espérant qu'il vous aide à débuter et qu'il vous encourage à continuer avec PostgreSQL.
Ce document a pour but de vous aider à installer PostgreSQL sous Windows ou sous Linux, et à commencer à développer.
Il est écrit pour vous faire gagner du temps dans vos premiers pas avec PostgreSQL, tout en vous expliquant les points importants afin que vous puissiez progresser par vous-même. Il s'adresse donc principalement aux développeurs d'applications, afin de leur permettre de découvrir ce puissant moteur sur une petite base de test, ou aux personnes qui débutent complètement avec PostgreSQL. Vous n'aurez pas besoin de connaissances système avancées pour suivre ce document.
Une fois que vous aurez terminé la lecture de ce document, vous pourrez continuer par la lecture de la documentation officielle pour apprendre à administrer PostgreSQL ou devenir un développeur aguerri. La dernière section de ce document vous donne les liens et références nécessaires pour continuer à progresser. Parfois les informations ne sont volontairement pas complètes, et lorsque la documentation de référence est plus claire et précise que ce qui aurait pu être fait ici, les liens sont fournis vers la documentation française.
Ce document a été écrit initialement pour la version 8.3, puis mis à jour pour la version 9.0 (voir le chapitre sur les versions).
Avertissement : ce document n'est en aucun cas un document sur le tuning de la base. Il n'est pas fait non plus pour vous apprendre à administrer une base de production.
PostgreSQL est un moteur de bases de données relationnelle. C'est un moteur adapté à des bases métier, donc riche en fonctionnalités et puissant. Son installation est cependant plutôt simple. Il faut juste comprendre quelques principes de base (ce que cette présentation s'efforce de faire)
Si vous ne connaissez pas les principes relationnels ou le SQL, le mieux est de vous procurer un bon ouvrage sur le sujet. L'article de Wikipedia peut être une bonne introduction (http://fr.wikipedia.org/wiki/SQL), et donne de nombreuses références. Le tutoriel de la documentation PostgreSQL peut également vous rendre service si vous avez besoin de vous rafraîchir la mémoire : http://docs.postgresqlfr.org/9.0/tutorial-sql.html
La licence de PostgreSQL est une licence de type BSD, ce qui permet son utilisation sans restriction, dans un logiciel libre ou propriétaire. C'est un avantage certain, car cela permet par exemple d'utiliser PostgreSQL comme base de données pour un logiciel propriétaire.
PostgreSQL est un projet indépendant. Il n'est détenu par aucune entreprise. La communauté PostgreSQL est très réactive (allez voir les mailings-lists si vous voulez vérifier). De nombreuses entreprises soutiennent et participent également au développement de PostgreSQL.
PostgreSQL comporte de nombreuses fonctionnalités intéressantes. Parmi celles-ci, on peut citer par exemple : moteur transactionnel respect des normes SQL MVCC (mécanisme permettant une concurrence efficace sans verrouiller les enregistrements pour assurer l'isolation des transactions) procédures stockées dans de nombreux langages triggers réplication maître-esclaves en continu par application des journaux binaires (archives WAL), esclaves accessibles en lecture.
PostgreSQL est conçu pour être robuste (aucune version ne sort sans avoir subi une suite extensive de tests) et peut supporter des volumes importants de données (ainsi par exemple Météo France gère une base de 3,5To).
PostgreSQL est conçu pour pouvoir supporter des extensions. Des extensions et outils sont disponibles pour compléter le moteur, par exemple :
Avant de passer aux procédures d'installation proprement dites, il est nécessaire de comprendre certaines notions fondamentales.
Une base est un ensemble structuré de données. On utilise généralement une base de donnée par application. Pour pouvoir créer une base de données, vous devez disposer d'un cluster de bases de données.
Un cluster est un ensemble de bases de données qui partagent les mêmes ressources (processus, mémoire, disque...) .
Un schéma est un espace de nommage au sein d'une base de données.
Les processus de PostgreSQL utilisent un compte système. Généralement c'est le compte postgres qui est utilisé pour cela, sauf si vous avez installé PostgreSQL sur votre compte (voir la partie compilation).
Les droits de la base de données sont gérés par des rôles. Avant de pouvoir vous connecter à la base de données, le rôle que vous utilisez doit avoir les autorisation nécessaires.
http://docs.postgresql.fr/9.0/user-manag.html
À retenir: les comptes systèmes et les rôles de base de données sont distincts! Même s'il y a des possibilités de mapping entre les deux (cf. paragraphe sur pg_hba.conf) La confusion entre ces 2 notions est une des causes fréquentes d'erreurs et de problèmes d'installation pour les débutants.
Les versions majeures comprennent le chiffre avant le point et un chiffre après. Exemple : 8.2 et 8.3 sont des versions majeures différentes. Les versions mineures incrémentent la 3ème partie : exemple : 8.3.7 Pour changer de version mineure, il suffit de mettre à jour le moteur. Mais pour changer de version majeure, il est nécessaire de décharger puis recharger les données.
Plus d'informations ici : http://www.postgresql.org/support/versioning
PostgreSQL est une application client/serveur. Le serveur gère les fichiers de la base de données, accepte les connexions des clients, et effectue les opérations demandées par les clients (requêtes...) Le client peut prendre de nombreuses formes. Il existe par exemple un client en ligne de commande (psql), des clients graphiques (par exemple pgAdmin3)... Le client peut être sur la même machine que le serveur, ou bien communiquer avec lui par le réseau.
Sous Windows, le serveur PostgreSQL tourne en tant que service. Sous Linux, ce sont des démons système qui effectuent ces tâches. (si vous êtes curieux, vous pouvez aller voir cet article : http://dalibo.org/glmf112_les_processus_de_postgresql) Il ne faut pas arrêter les processus du serveur n'importe comment. Pour arrêter le serveur, il faut utiliser les outils fournis (voir la section sur l'arrêt et le démarrage du serveur). NB : par défaut, PostgreSQL est configuré pour écouter sur le port 5432. Les outils se connectent par défaut sur ce port : pensez à cela si vous devez modifier ce paramètre.
Ce sont des extensions intéressantes, maintenues par le projet, mais non intégrées au coeur du moteur. Exemples :
Pour l'installation et la suite, nous prendrons l'exemple de la création d'une base de données mabase, qui sera utilisée et gérée par un utilisateur tom.
À partir de la version 8.0, PostgreSQL fonctionne nativement sous Windows (Windows XP, Windows 2000, Windows 2003, Vista, Windows 2008...). Malgré tout, seules les versions à partir de la 8.2 sont supportées sous Windows. Il s'installe en tant que service.
NB : si vous regardez dans la liste des processus, plusieurs processus postgres sont présents. Gardez à l'esprit que la mémoire est partagée entre ces processus : la mémoire utilisée par PostgreSQL est donc inférieure à la somme de la mémoire utilisée par chaque processus qui est affichée dans le gestionnaire de tâches...
Vous pouvez trouver deux types d'installeurs pour Windows : l'installeur "en un clic", ou l'installeur "pgInstaller". Le premier est créé par EnterpriseDB, le seconde par la communauté. Vous les trouverez à partir d'ici : http://www.postgresql.org/download/windows "pgInstaller" n'est disponible que pour les versions 8.2 et 8.3, le document détaille donc le processus d'installation pour l'installeur «en un clic ». NB: il est possible de récupérer les binaires sans l'installeur (pour utilisateurs avancés uniquement), ou de faire une installation silencieuse (voir sur le site de EnterpriseDB)
Lancez l'installeur (pour Postgresql 9.0, le fichier s'appelle : postgresql-9.0.0-1-windows.exe )
NB: L'installeur logue toutes ses actions dans un fichier install-postgresql.log qui est dans le répertoire %TEMP% de Windows. En cas de problème, consulter ce fichier.

Le répertoire est celui où vont s'installer le programme serveur (postgres.exe) et les outils client (psql, pgdump...), ainsi que la documentation, etc...
L'installeur ne permet actuellement pas d'installer les outils client et le serveur séparément.

L'installeur demande ensuite où sera créé le cluster de données. Il sera par la suite toujours possible de créér d'autres cluster avec l'outil initdb.

L'installeur demande le mot de passe de l'utilisateur postgres. Attention, en réalité ceci recouvre 2 notions différentes : un utilisateur du système d'exploitation, celui sur le compte duquel fonctionnent les programmes du serveur, le super-utilisateur de base de données. Ils peuvent très bien avoir des noms et des mots de passe différents, mais pour cet installeur, il a été choisi de donner le même nom et le même mot de passe.
Si l'utilisateur postgres du système d'exploitation existe déjà, il faut donner le mot de passe existant. Si vous l'avez oublié, vous pouvez le changer dans une console avec la commande net user :
net user postgres <motdepasse>
Attention à ne pas mettre un mot de passe trivial à l'utilisateur postgres (c'est encore plus important si vous autorisez les connexions à partir du réseau!). Évitez également de lui donner le même mot de passe que celui de l'utilisateur système postgres. En effet, l'utilisateur postgres dispose de tous les droits sur le cluster.

Par défaut, le port sur lequel le serveur attend les connexions est le port 5432. Vous pouvez changer le numéro de port d'écoute. Attention dans ce cas à configurer correctement vos clients (JDBC, etc...)
Remarque : par défaut, postgres n'acceptera pas les connexions à partir du réseau. Ceci est parfait sur un poste de développement autonome, mais pas pour un serveur. Cela pourra être modifié par configuration.

La locale définit le comportement du cluster pour les opérations de tri (ordre alphabétique) … Par défaut, c'est celle du système qui est utilisée, mais vous pouvez en préférer une autre.

Si vous êtes certain(e) du paramétrage, vous pouvez cliquer sur « Suivant».

L'installation est terminée. Si vous souhaitez installer des modules complémentaires (phppgAdmin, Slony...), lancez l' outil Stackbuilder.

L'installation sous Windows est prête à être utilisée. Dans le menu démarrer, vous pouvez retrouver tous les outils utiles pour gérer le serveur.
Si vous avez conservé les options par défaut, les fichiers du cluster se trouvent dans C:\Program Files\PostgreSQL\9.0, et vous trouverez l'outil pour désinstaller dans le même répertoire.
NB : notes sur la console Windows et psql La console Windows est par défaut dans un encodage compatible DOS (par exemple CP850). Lorsque vous démarrerez psql pour la première fois, vous aurez le message d'avertissement suivant :
Attention : l'encodage console (850) diffère de l'encodage Windows (1252). Les caractères 8 bits peuvent ne pas fonctionner correctement. Voir la section « Notes aux utilisateurs de Windows » de la page référence de psql pour les détails.
Il est recommandé de modifier l'encodage de la console, Pour éviter cela, vous pouvez éditer le fichier C:\Program Files\PostgreSQL\9.0\scripts\runpsql.bat en ajoutant la ligne :
chcp 1252
avant le lancement de psql.
Remarque importante : si vous avez installé PostgreSQL sur un poste de travail (dans le but par exemple de l'évaluer ou de vous familiariser avec lui), vous avez maintenant une installation qui fonctionne « à la sortie de la boîte », et vous pouvez commencer à l'utiliser via l'outil pgAdmin (crééer des bases, etc...). Mais si vous souhaitez autoriser des connexions distantes, il est indispensable de lire la suite du document. Il apporte également des informations qui pourraient vous être utiles (emplacement et rôle des différents répertoires...) même si vous utilisez peu les outils en ligne de commande. Vous pouvez maintenant passer à la section « après l'installation » si vous le souhaitez.
Dans toute la suite du document, nous supposons que l'utilisateur système sous lequel PostgreSQL a été installé est postgres. Si ce n'est pas le cas, remplacez par l'utilisateur qui démarre le serveur. Conseil : avant toute modification de fichier de configuration, pensez à sauvegarder la version initiale du fichier! Une erreur est si vite arrivée...
L'emplacement des fichiers de configuration et des fichiers du cluster dépend de votre distribution. Le répertoire contenant les fichiers du cluster est couramment appelé PGDATA (du nom de la variable d'environnement correspondante). Par exemple : /var/lib/pgsql/data (Linux) ou C:\Program Files\PostgreSQL\9.0\data (Windows) Normalement, le fichier postgresql.conf est dans le répertoire du cluster. Cependant, cela peut être autrement (sur Debian, tous les fichiers de configuration doivent être dans /etc) Voici un moyen de retrouver leur emplacement sous Linux ou Unix si vous l'avez oublié. Liste des processus nommés "postgres" : (exemple sur une Debian):
flo:~# ps -ef | grep postgres | grep -v grep postgres 2797 1 0 06:14 ? 00:00:00 /usr/lib/postgresql/9.0/bin/postgres -D /var/lib/postgresql/9.0/main -c config_file=/etc/postgresql /9.0/main/postgresql.conf postgres 2798 2797 0 06:14 ? 00:00:00 postgres: logger process postgres 2800 2797 0 06:14 ? 00:00:00 postgres: writer process postgres 2801 2797 0 06:14 ? 00:00:00 postgres: wal writer process postgres 2802 2797 0 06:14 ? 00:00:00 postgres: autovacuum launcher process postgres 2803 2797 0 06:14 ? 00:00:00 postgres: stats collector process flo:~#
Voyez que le processus 2797 est le père de tous les autres :
postgres 2797 1 0 06:14 ? 00:00:00 /usr/lib/postgresql/9.0/bin/postgres -D /var/lib/postgresql/9.0/main -c config_file=/etc/postgresql/9.0/main/postgresql.conf
le chemin derrière le -D est l'emplacement du cluster. Celui derrière le -c l'emplacement du fichier de configuration.
config_file=/etc/postgresql/9.0/main/postgresql.conf
Normalement, les autres fichiers de configuration du cluster (pg_hba.conf, pg_ident.conf) sont dans le même répertoire .
/usr/lib/postgresql/9.0/bin/postgres
est l'emplacement des binaires.
Arborescence du répertoire du cluster:
flo:/var/lib/postgresql/9.0/main# ls -l total 48 drwx-- 11 postgres postgres 4096 mai 10 15:19 base drwx-- 2 postgres postgres 4096 mai 10 18:29 global drwx-- 2 postgres postgres 4096 avr 4 19:58 pg_clog drwxr-xr-x 2 postgres postgres 4096 mai 10 08:15 pg_log drwx-- 4 postgres postgres 4096 avr 4 19:58 pg_multixact drwx-- 2 postgres postgres 4096 avr 4 19:58 pg_subtrans drwx-- 2 postgres postgres 4096 avr 4 19:58 pg_tblspc drwx-- 2 postgres postgres 4096 avr 4 19:58 pg_twophase -rw--- 1 postgres postgres 4 avr 4 19:58 PG_VERSION drwx-- 3 postgres postgres 4096 avr 4 19:58 pg_xlog -rw--- 1 postgres postgres 133 mai 10 08:15 postmaster.opts -rw--- 1 postgres postgres 54 mai 10 08:15 postmaster.pid lrwxrwxrwx 1 root root 31 avr 4 19:58 root.crt -> /etc/postgresql-common/root.crt
Quelques sous-répertoires et fichiers :
Attention : le contenu de pg_clog et pg_xlog ne doit pas être supprimé!
À moins que vous n'ayez compilé les sources pour utiliser PostgreSQL sur votre compte utilisateur, un utilisateur postgres a été créé sur votre système. Afin de pouvoir l'utiliser, vous devez changer le mot de passe de cet utilisateur. Pour cela, sous Linux, connectez-vous en tant que root et exécutez la commande 'passwd postgres'. (ne pas utiliser un mot de passe trivial!)
Avec certaines distributions (Redhat, Debian), un cluster est créé par défaut à l'installation des paquets. De même pour l'installation sous Windows. Si vous êtes dans un autre cas de figure, il vous faudra donc en créer un. Pour cela, utilisez la commande initdb.
L'installation de PostgreSQL positionne des valeurs par défaut dans les fichiers de configuration. Après l'installation, PostgreSQL est configuré de telle sorte que les connexions ne sont pas possibles à partir du réseau. Pour autoriser des clients distants à se connecter, il faut configurer deux fichiers : postgresql.conf et pg_hba.conf.
À l'installation, PostgreSQL est configuré pour n'accepter que les connexions locales (c'est le paramètre listen_addresses). Si vous souhaitez pouvoir vous connecter à partir du réseau, il faut dé-commenter le paramètre listen_addresses du fichier postgresql.conf, et préciser sur quelle(s) adresse(s) postgres accepte les connexions.
Attention : ce sont bien les adresses IP d'écoute, c'est-à-dire les adresses IP du serveur sur lesquelles le serveur PostgreSQL va écouter. Si vous précisez une adresse '*', postgres va écouter les connexions sur toutes les interfaces réseau du serveur. Si vous précisez une adresse IP, cela signifie que postgres va écouter sur l'interface réseau de votre machine qui a cette adresse IP. Si vous souhaitez n'autoriser les connexions qu'à une liste de machines ou d'adresses IP, c'est dans pg_hba.conf que vous pouvez le faire (paragraphe suivant). Pour que les paramètres soient pris en compte, il faut redémarrer le serveur PostgreSQL. Exemples : (connexion locales)
#listen_addresses = 'localhost' # what IP address(es) to listen on;
# comma-separated list of addresses;
# defaults to 'localhost', '*' = all
# (change requires restart)
port = 5432 # (change requires restart)@@
(connexion sur l'adresse 192.168.0.4 et local, port 5433)
listen_addresses = '192.168.0.4, localhost' # what IP address(es) to listen on;
# comma-separated list of addresses;
# defaults to 'localhost', '*' = all
# (change requires restart)
port = 5432 # (change requires restart)@@
Le fichier pg_hba.conf configure les autorisations pour les bases du cluster. Chaque ligne précise une règle aidant à décider si l'utilisateur est habilité à se connecter ou non. Le fichier est lu dans l'ordre par postgres, et, dès qu'une ligne est rencontrée qui correspond au cas testé, la lecture s'arrête. Cela signifie que l'ordre des lignes est important. Sur chaque ligne est précisé le type de connexion, un nom de base de données, un nom d'utilisateur, et la méthode d'authentification. Les méthodes d'authentification les plus classiques sont : md5 (par mot de passe crypté), ident (à partir du nom d'utilisateur du système d'exploitation, non utilisable sous Windows).
Exemple :
# connection par socket Unix pour l'administration du serveur # TYPE DATABASE USER CIDR-ADDRESS METHOD local all postgres ident sameuser # connection par socket Unix # TYPE DATABASE USER CIDR-ADDRESS METHOD local mabase tom md5 local truc all ident sameuser # Connexions locales en Ipv4 : # TYPE DATABASE USER CIDR-ADDRESS METHOD host mabase tom 127.0.0.1/32 md5 host truc all 127.0.0.1/32 md5 # Connexion distante en Ipv4 : # TYPE DATABASE USER CIDR-ADDRESS METHOD host mabase tom 192.168.12.10/32 md5 host truc all 192.168.12.10/32 md5
La première ligne :
local all postgres ident sameuser
signifie que, si postgres reçoit une demande de connexion sur n'importe quelle base (all) par socket Unix (local), pour l'utilisateur postgres, alors la méthode d'authentification utilisée est : ident. sameuser signifie que postgres vérifie que le nom de l'utilisateur Unix propriétaire de la socket est le même que celui utilisé pour se connecter à la base.
La ligne suivante :
local mabase tom md5
signifie que, lorsque tom essaie de se connecter par socket Unix sur la base mabase, c'est l'authentification md5 qui est utilisée.
La ligne :
local truc all ident sameuser
signifie que lorsque n'importe que n'importe quel utilisateur essaie de se connecter à la base truc par socket Unix, c'est l'authentification ident sameuser qui est utilisée.
La ligne :
host mabase tom 127.0.0.1/32 md5
signifie qu'une demande de connexion à partir pour la base mabase, par un utilisateur tom, en local par Ipv4 est authentifiée par md5.
La ligne :
host mabase tom 192.168.12.10/32 md5
signifie qu'une demande de connexion de l'utilisateur tom sur mabase, à partir de l'adresse 192.168.12.10 est authentifiée par md5.
On voit donc que tom est autorisé à se connecter sur la base mabase, soit par socket Unix, soit par Ipv4 en local, soit par Ipv4 à partir de : 192.168.12.10. Les autres utilisateurs (à part l'utilisateur postgres) ne peuvent se connecter que sur la base truc. Tom peut également se connecter sur la base truc, car tom fait partie de l'ensemble des utilisateurs (all). NB : CIDR est une façon de noter les ensembles d'adresses IP, avec le chiffre derrière le '/' indiquant la taille du masque en bits (ainsi un réseau de classe A est en /8, classe B, 16, classe C, 24, une IP unique /32, et tout le monde : 0.0.0.0/0 ) (voir l'article Wikipedia : http://fr.wikipedia.org/wiki/Adresse_IPv4 )
Remarques : Le fichier configure le cluster, il est donc commun à toutes les bases du cluster : attention à ne pas autoriser un utilisateur sur une base par erreur. Attention, ne surtout pas autoriser d'authentification trust ni ident par le réseau, parce que cela signifierait faire entièrement confiance au client... Si vous voulez en savoir plus sur l'authentification du client, allez voir la documentation ici : http://docs.postgresql.fr/9.0/client-authentication.html
Pour que PostgreSQL prenne en compte les modifications de paramètres sans redémarrer le serveur, vous avez les solutions suivantes :
Sous Windows, il est possible d'utiliser un raccourci dans le menu Démarrer (« Rechargez la configuration »).
Attention : certaines options ne sont prises en compte qu'au démarrage (voir la documentation, les commentaires de postgresql.conf ou la colonne context de la vue pg_settings)
Nous allons créer une base mabase sur le cluster, puis faire de tom le propriétaire de la base (afin qu'il puisse faire ce qu'il veut sur cette base)
postgres@flo:/etc/postgresql/9.0/main$ pg_lsclusters Version Cluster Port Status Owner Data directory Log file 9.0 main 5432 online postgres /var/lib/postgresql/9.0/main custom
Pour cela, lancez la commande createdb :
postgres@flo$ createdb mabase
NB : createdb lance en fait la commande CREATE DATABASE pour vous.
NB : les utilisateurs et les groupes sont tous gérés par des rôles.
En tant qu'utilisateur postgres, lancez psql :
postgres@flo:/usr/share/doc/postgresql-common$ psql Bienvenue dans psql 9.0.6, l'interface interactive de PostgreSQL.
Saisissez:
\copyright pour les termes de distribution
\h pour l'aide-mémoire des commandes SQL
\? pour l'aide-mémoire des commandes psql
\g ou point-virgule en fin d'instruction pour exécuter la requête
\q pour quitter
postgres=#
Créez un rôle tom, avec les droits de login (pour qu'il ait le droit de se connecter au serveur), et le mot de passe : secret.
postgres=# CREATE ROLE tom LOGIN password 'secret'; CREATE ROLE postgres=#
Pour que tom soit le propriétaire de mabase :
postgres=# ALTER DATABASE mabase OWNER TO tom; ALTER DATABASE
Sortez de psql :
postgres=# \q postgres@flo:/usr/share/doc/postgresql-common$
NB : les commandes CREATE DATABASE et CREATE ROLE (création de base et d'utilisateur) sont globales au cluster. Il est donc possible de les exécuter de n'importe quelle base.
Maintenant, l'utilisateur tom peut se connecter sur mabase : lancez psql, en précisant que vous vous connectez en tant que tom :
flo@flo:~$ psql -U tom mabase Mot de passe pour l'utilisateur tom : Bienvenue dans psql 9.0.6, l'interface interactive de PostgreSQL.
Saisissez:
\copyright pour les termes de distribution
\h pour l'aide-mémoire des commandes SQL
\? pour l'aide-mémoire des commandes psql
\g ou point-virgule en fin d'instruction pour exécuter la requête
\q pour quitter
mabase=>
Remarque : il faut préciser la base! Sinon psql cherchera à se connecter à une base "tom".
Si vous souhaitez donner le droit à tom de créer des bases:
postgres=# ALTER ROLE tom CREATEDB; ALTER ROLE postgres=#
Pour les détails sur les droits, lisez le chapitre correspondant de la documentation : http://docs.postgresqlfr.org/9.0/privileges.html
Le super-utilisateur est un utilisateur qui dispose de droits spéciaux (certaines fonctions ne sont utilisables que par un super-utilisateur). Les super-utilisateurs passent au travers des vérifications de droits. Si vous avez installé PostgreSQL en tant que root, classiquement vous avez un super-utilisateur postgres. Attention! Le super-utilisateur disposant de tous les droits, éviter de l'utiliser si ce n'est pas nécessaire, afin de limiter le risque d'erreur.
Que vérifier?
NB : vous obtenez la liste des bases d'un cluster avec la commande \l dans psql
La configuration de la log est effectuée par le fichier postgresql.conf (voir les paramètres log_destination et log_directory) Dans une installation standard de PostgreSQL, la log se trouve dans un répertoire pg_log sous le répertoire PGDATA (répertoire du cluster). Par exemple, sous Windows :
C:\Program Files\PostgreSQL\9.0\data\pg_log
En fonction de votre utilisation (production, test, développement), vous pourrez régler les paramètres de la log. Par exemple, loguer tous les ordres SQL peut être fort utile en développement (surtout lorsque vous utilisez un ORM).
Pensez à recharger la configuration après modification.
Sous Windows : vous pouvez utiliser "stoppez le service" et "démarrez le service" dans le menu démarrer, ou bien dans un terminal, utiliser pg_ctl :
C:\Program Files\PostgreSQL\9.0\bin>pg_ctl start -D "C:\Program Files\PostgreSQL\9.0\data" server starting
Sous Linux : c'est la commande pg_ctl (sous Debian : pg_ctlcluster ou service postresql start
sous Redhat)
PgAdmin3 est sans doute l'outil le plus populaire pour développer et administrer PostgreSQL.
http://www.pgadmin.org/?lang=fr_FR
Voici un apercu de ce à quoi il ressemble. Pour le reste, vous pourrez vous reporter à sa documentation.
Psql permet d'exécuter des ordres SQL sur les bases, et également des commandes de gestion et d'administration. Pour lancer psql :
Remarque : si, à la première connexion, vous avez ce message d'avertissement :
Warning: Console code page (437) differs from Windows code page (1252)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details.
postgres=#
reportez-vous à la partie installation sous Windows.
Si vous lancez psql non pas avec le menu démarrer, mais à partir d'une console Windows, il faut être connecté en tant qu'utilisateur système postgres. Ceci est possible avec la commande runas de Windows.
runas user:postgres cmd.exe
Puis modifiez la police de la console pour utiliser Lucida Console, et changez de code page :
cmd.exe /c chcp 1252
(pour la France)
Malheureusement, si votre base est en UTF8, la console Windows est incapable de gérer correctement l'affichage. Il faudra également éviter de saisir des données avec psql, et préférer pgAdmin pour cet usage (pgAdmin gère parfaitement les différents encodages).
psql mabase
Si vous ne précisez pas le nom de la base, psql essaie de se connecter à la base de même nom que l'utilisateur. Si vous ne précisez pas le nom d'utilisateur, c'est le nom de l'utilisateur du système qui est utilisé.
Commandes psql à connaître absolument :
autres commandes intéressantes :
Attention! Pour la commande \i, les noms de fichiers sous Windows doivent utiliser le séparateur slash " / "et non antislash " \ " . Exemple :
\i C:/tests.sql
C'est un outil d'administration web pour PostgreSQL http://phppgadmin.sourceforge.net/
copy est un outil pour le chargement et déchargement de données en masse. Ce n'est pas une commande standard SQL. http://docs.postgresqlfr.org/9.0/sql-copy.html
Plusieurs outils permettent d'exécuter du code SQL de façon interactive : psql, pgAdmin (voir les sections qui leur sont consacrées). Vous pouvez également utiliser un outil tiers, si vous préférez...
L'intérêt des procédures stockées est de pouvoir exécuter des fonctions directement sur le serveur. Les procédures stockées sont efficaces et rapides, et permettent de traiter des données, soit pour consultation par un client, soit en mise à jour.
PostgreSQL vous donne le choix du langage de procédures stockées.
Vous pouvez utiliser:
Le pilote JDBC pour PostgreSQL est un pilote natif (il est entièrement écrit en Java)
Les différentes versions du pilote JDBC sont disponibles ici (ainsi que la documentation)
http://jdbc.postgresql.org/index.html
Ensuite vous avez juste à utiliser le .jar de manière classique (le mettre dans le CLASSPATH de votre application)
NB : la syntaxe de l'URL
String url="jdbc:postgresql:test_conn";
L'URL a une de ces formes :
Allez voir la documentation http://jdbc.postgresql.org/documentation/83/connect.html pour plus de détails.
Quel driver prendre ?
Normalement, la dernière version du driver devrait vous convenir (elle est compatible avec toutes les versions supportées de PostgreSQL). Mais il y en a 2 variétés : la JDBC3, à préférer pourt les JVM 1.4 et 1.5, et la JDBC4, pour la JVM 1.6. Plus de précisions et une matrice de compatibilité sur la page de téléchargement : http://jdbc.postgresql.org/download.html
Voir ici : http://docs.postgresqlfr.org/9.0/external-projects.html
Le nom des objets dans les ordres SQL est converti automatiquement en minuscules.
Par exemple, si vous exécutez :
SELECT Id, Valeur FROM Matable;
l'ordre réellement exécuté sera :
SELECT id, valeur FROM matable;
mabase=> SELECT Id, Valeur FROM Matable; id | valeur+1 | azerty (1 ligne)
mabase=>
Si vous souhaitez utiliser la casse dans les noms d'objets (ce qui n'est pas conseillé en général), utilisez les guillemets.
Par exemple :
SELECT "Id", "Valeur" FROM "Matable";
Remarquez que ce comportement est différent d'autres moteurs, qui soit passent tous les noms en majuscule, soit conservent la casse. (Le comportement standard pour un SGBD est d'ignorer la casse, ainsi il est déconseillé généralement d'utiliser des noms d'objet avec des casses différentes : si vous utilisez toujours des minuscules, le comportement sera toujours le même, quel que soit le SGBD)
Avec PostgreSQL, lorsqu'une erreur se produit dans une transaction, il n'est pas possible de l'ignorer. L'erreur doit être gérée. Sinon tous les ordres suivants sont également en erreur. De plus, à la fin de la transaction, il n'est pas possible de commiter. L'ordre COMMIT provoque en réalité un ROLLBACK.
Exemple :
mabase=> begin;
BEGIN
mabase=> insert into matable(valeur, nb) values ('c',2);
INSERT 0 1
mabase=> insert into matable(valeur, nb) values ('c',2);
ERREUR: la valeur d'une clé dupliquée rompt la contrainte unique « u_matable »
mabase=> insert into matable(valeur, nb) values ('d',2);
ERREUR: la transaction est annulée, les commandes sont ignorées jusqu'à la fin du bloc
de la transaction
mabase=> commit;
ROLLBACK
mabase=> select valeur, nb from matable;
valeur | nb
+
a | 2
b | 2
(2 lignes)
mabase=>
Les savepoints ne sont pas spécifiques à PostgreSQL. Mais c'est une fonctionalité SQL trop peu connue, et pourtant extrêmement utile, dans le cas de traitements lourds.
Un savepoint sert à marquer un point de reprise dans un traitement. Lorsque vous avez à effectuer un traitement long (par exemple lorqu'un programme doit mettre à jour tout un ensemble de données les unes après les autres), vous pouvez mettre des savepoints à intervalles réguliers. Lorsqu'une erreur se produit, vous faites en sorte que le programme effectue un ROLLBACK TO SAVEPOINT vers un point de sauvegarde où l'état de vos données est cohérent (généralement le dernier point de sauvegarde). Ensuite vous pouvez annuler le traitement (après par exemple pris la précaution de loguer les événements...)
L'intérêt est que seul les traitements effectués après le point de sauvegarde sont perdus. Cela évite à votre programme de faire un ROLLBACK sur l'ensemble du traitement! Votre programme peut ainsi effectuer des traitements partiellement.
Une des fonctionnalités les plus épatantes de PostgreSQL est la possibilité d'inclure des ordres DDL dans des transactions.
Exemple :
Dans une transaction, on crée une table "test", puis une table "matable". La création de "matable" échoue (la table existe déjà). On fait un rollback sur la transaction : la table "test" n'existe pas.
mabase=> BEGIN;
BEGIN
mabase=> CREATE TABLE test (
id serial NOT NULL,
valeur character varying(20) NOT NULL);
NOTICE: CREATE TABLE créera des séquences implicites « test_id_seq » pour la colonne serial « test.id »
CREATE TABLE
mabase=> ALTER TABLE test ADD CONSTRAINT pk_test PRIMARY KEY (id);
NOTICE: ALTER TABLE / ADD PRIMARY KEY créera un index implicite « pk_test » pour la table « test »
ALTER TABLE
mabase=> CREATE TABLE matable (
id serial NOT NULL,
valeur character varying(20) NOT NULL);
NOTICE: CREATE TABLE créera des séquences implicites « matable_id_seq1 » pour la colonne serial « matable.id »
ERREUR: la relation « matable » existe déjà
mabase=> ROLLBACK;
ROLLBACK
mabase=> \d
Liste des relations
Schéma | Nom | Type | Propriétaire
+++--
public | matable | table | tom
public | matable_id_seq | séquence | tom
public | table_flo | table | flo
public | table_flo_id_seq | séquence | flo
(4 lignes)
mabase=>
Intérêt :
On peut faire tout un ensemble de modification de façon atomique (par exemple la migration d'un schéma pour l'évolution d'une application), C'est un soulagement pour le DBA qui devra passer votre script de migration, de nuit, de savoir qu'il n'aura pas à restaurer la base en cas d'échec.
En raison de l'implémentation actuelle du MVCC, count(*) force le parcours complet de la table, ce qui est donc lent.
Lien vers la documentation en Français : http://docs.postgresql.fr/ En anglais : [http://www.postgresql.org/docs/ |http://www.postgresql.org/docs/|en]
http://www.postgresql.org/ : site officiel http://www.postgresql.fr/ : site de la communauté francophone.
La communauté PostgreSQL est très active, et vous trouverez facilement de l'aide pour les problèmes les plus simples aussi bien que pour les cas les plus tordus.
La liste francophone : http://archives.postgresql.org/pgsql-fr-generale/ Les autres : http://www.postgresql.org/community/lists/ Attention : les listes "developer" sont pour les développeurs DE PostgreSQL uniquement !
Si vous posez une question parce que vous avez un problème, vous voulez certainement qu'il soit résolu le plus vite possible. Alors pensez à ceux qui vont tenter de vous aider, et faites-leur gagner du temps en donnant les informations nécessaires. Soyez le plus clair possible.
Pensez à préciser au minimum :
Si vous n'arrivez pas à vous connecter, précisez si le client est sur la même machine que le serveur. Recopiez les messages d'erreurs, consultez la log... enfin donnez le maximum d'informations pertinentes, et si on vous pose des questions, répondez-y le plus précisément possible.
Evitez également de dire qu'il y a un bug si vous n'en êtes pas absolement certain(e), et postez sur la mailing-list ou le forum approprié (par exemple, la mailing-list pour les novices n'est pas un endroit indigne, et des hackers y répondent régulièrement et avec bienveillance)
FOSDEM 2012 - PostgreSQL Devroom: l'appel à conférenciers est lancé (date limite de dépôt : 20 décembre 2011) : https://www.postgresql.eu/events/callforpapers/fosdem2012/
Offres d'emplois autour de PostgreSQL en novembre
PostgreSQL Local
PostgreSQL dans les média
PostgreSQL Weekly News / les nouvelles hebdomadaires vous sont offertes cette semaine par David Fetter. Traduction par l'équipe PostgreSQLFr sous licence CC BY-NC-SA.
Proposez vos articles ou annonces avant dimanche 15:00 (heure du Pacifique). Merci de les envoyer en anglais à david (a) fetter.org, en allemand à pwn (a) pgug.de, en italien à pwn (a) itpug.org et en espagnol à pwn (a) arpug.com.ar.
(lien vers l'article original)
Revues de code
Correctifs appliqués
Tom Lane a poussé :
Simon Riggs a poussé :
Peter Eisentraut a poussé :
Robert Haas a poussé :
Bruce Momjian a poussé :
Heikki Linnakangas a poussé :
Alvaro Herrera a poussé :
Andrew Dunstan a poussé :
Correctifs rejetés (à ce jour)
Correctifs en attente
FOSDEM 2012 - PostgreSQL Devroom: l'appel à conférenciers est ouvert jusqu'au 20 décembre 2011 : https://www.postgresql.eu/events/callforpapers/fosdem2012/
Les nouveautés des produits dérivés
Offres d'emplois autour de PostgreSQL en novembre
PostgreSQL Local
PostgreSQL dans les média
PostgreSQL Weekly News / les nouvelles hebdomadaires vous sont offertes cette semaine par David Fetter. Traduction par l'équipe PostgreSQLFr sous licence CC BY-NC-SA.
Proposez vos articles ou annonces avant dimanche 15:00 (heure du Pacifique). Merci de les envoyer en anglais à david (a) fetter.org, en allemand à pwn (a) pgug.de, en italien à pwn (a) itpug.org et en espagnol à pwn (a) arpug.com.ar.
(lien vers l'article original)
Revues de code
Correctifs appliqués
Bruce Momjian a poussé :
Tom Lane a poussé :
Robert Haas a poussé :
Michael Meskes a poussé :
Alvaro Herrera a poussé :
Simon Riggs a poussé :
Correctifs rejetés (à ce jour)
Correctifs en attente
Symfony 2 propose une abstraction des entities très intéressante grâce à Doctrine. Je poste ce petit article car j’ai eu une erreur tout simple:
$ php app/console doctrine:schema:update --force Updating database schema... [PDOException] SQLSTATE[42601]: Syntax error: 7 ERREUR: erreur de syntaxe sur ou près de « User » LINE 1: CREATE TABLE User (id INT NOT NULL, username VARCHAR(255) NO... ^
En fait, j’ai créé un bundle nommé User, et doctrine souhaite donc créer la table User. Le problème, c’est que user est un mot clé réservé dans PostgreSQL. Par conséquent, il faut donc forcer Doctrine à escaper le nom de la table. Pour se faire, il suffit d’ajouter une annotation Table en préfixant et suffixant le nom de la table par `.
Voici par exemple ma classe User avant la correction:
/** * @ORM\Entity */ class User extends BaseUser { // ... }
Il suffit donc de d’ajouter l’annotation @ORM\Table en spécifiant le nom de la table entouré de `. Le nouveau code est:
/** * @ORM\Entity * @ORM\Table(name="`User`") */ class User extends BaseUser { // ... }
Ainsi, Doctrine va générer ses requêtes en ajoutant des caractères d’échappement sur le nom de la table. Ainsi, vous n’aurez plus d’erreur!
Changer de système de gestion de bases de données n’est que rarement une tâche simple. L’une des premières étapes de la validation de la migration consiste à valider son intérêt en termes de coûts et de bénéfices, parfois aussi appelé « retour sur investissement ». J’ai lu récemment un article qui détaille des points techniques pour lesquels une migration vers PostgreSQL peut s’avérer coûteuse, Migration Oracle PostgreSQL : les 13 grandes lacunes qui peuvent s’avérer cauchemardesque.
Cet article est très intéressant et le point de vue exprimé me semble honnête et sincère, je regrette seulement que tout ne soit pas exact ou à jour dans les détails concernant PostgreSQL. Globalement, il est vrai que les concurrents propriétaires de notre solution Open Source favorite disposent encore de fonctionnalités avancées que nous ne retrouvons pas dans PostgreSQL, et cela peut s’avérer déstabilisant ou bien peut nuire à votre capacité à migrer vers PostgresQL.
Il faut se rendre compte que PostgreSQL n’étant pas édité par une entreprise unique, les fonctionnalités de chaque nouvelle version sont celles que les développeurs ont choisi d’implémenter. Pas de département Marketing pour arbitrer les éléments à ajouter dans cette fameuse liste qui aide les commerciaux à mieux faire leur travail. L’avantage de cette organisation est qu’elle permet à tout utilisateur de participer à établir les priorités du développement du projet, en contribuant les fonctionnalités manquantes. Cela peut se faire directement lorsque l’on dispose des compétences nécessaires en interne, ou bien en sponsorisant une entreprise spécialisée, telle 2ndQuadrant.
Pour être juste avec l’auteur de l’article précédent, rappelons tout de même qu’il détaille un point de vue technique d’administrateur de bases de données qui s’attache à résoudre les problèmes réels qui font son quotidien, la remarque sur l’influence du Marketing n’est pas une remarque sur l’article référencé ci-dessus.
Répondre aux 13 points cités serait trop long et trop technique pour le faire ici. Prenons tout de même le temps d’en relever quelques uns, qui illustrent l’attitude du projet PostgreSQL. La gestion des espaces de stockage, par exemple, est laissée aux programmes spécialisés (tels LVM), car les développeurs de PostgreSQL utilisent le système de fichiers et de blocs sous-jacents et refusent d’en dupliquer les fonctionnalités.
Quant à la gestion des transactions, rappelons qu’avec la sortie de PostgreSQL 9.1 plus tôt cette année, nous offrons la seule implémentation du niveau sérialisable qui ne repose pas sur des verrous forts et qui soit démontrée correcte. Ce qui fait défaut à PostgreSQL est la notion de procédure permettant de contrôler des transactions autonomes. Il est possible de contourner cette absence en utilisant les outils dblink ou plproxy, et je connais plusieurs société d’expertise qui seront heureuses de vous expliquer comment faire cela.
La partitionement dans PostgreSQL est un sujet qui mériterait un billet à lui tout seul. C’est un problème que nous voulons résoudre chez 2ndQuadrant, et nous avons plusieurs pistes afin d’arriver à une bonne solution. Sponsoriser nos travaux sur le sujet est un des meilleurs moyens à votre disposition afin de faciliter votre migration vers PostgreSQL dès la sortie de sa prochaine version majeure. Ce même raisonnement s’applique parfaitement aux requêtes parallèles, autre sujet important sur lequel nous saurons vous aider.
Il existe des moyens d’influencer l’optimisation de requêtes que réalise PostgreSQL, mais pas avec les fameux indices de requêtes. Utiliser ceux-ci pose de grands problèmes de compatibilité et demande de revoir l’ensemble des requêtes qui les utilisent pour toute migration à une version majeure plus récente de votre SBGD propriétaire, il me semble. Le compromis n’est pas si facile à faire.
Les index couvrants ont été développés (par Robert Haas, qui travaille pour EnterpriseDB) et seront disponibles dans PostgreSQL 9.2, sans avoir à déclarer quoi que ce soit. Si les seules colonnes dont vous avez besoin sont indexées, alors PostgreSQL saura seul en tirer parti. Le profilage de requête est grandement amélioré pour la prochaine version de PostgreSQL, suite à des travaux réalisés par 2ndQuadrant.
Enfin, PostgreSQL dispose en versions 9.0 et 9.1 d’une solution de réplication intégrée. Cela est le résultat des 7 dernières années de travaux de Simon Riggs (2ndQuadrant) concernant la gestion des journaux de transaction. En version 9.1 PostgreSQL propose une solution de réplication synchrone contrôlable pour chaque transaction. Vous pouvez faire cohabiter une réplication synchrone et une réplication asynchrone au sein de la même installation de bases de données afin de bénéficier simultanément des avantages de sécurité et durabilité des données sans nuire aux performances des transactions moins importantes. Une fois de plus, cela est une première mondiale, nul autre système de gestion de bases de données ne dispose d’une telle solution.
En conclusion, l’article que j’ai référencé au début de ce billet est une bonne lecture même s’il n’est pas suffisamment à jour. Certaines utilisations des SGBD propriétaires peuvent s’avérer difficiles à reproduire sous PostgreSQL et il est indispensable de savoir évaluer cela dès le début de l’analyse de faisabilité et de coûts. Dans bien des cas cependant, participer à la mise au point de la fonctionnalité manquante en en finançant le développement sera la meilleure stratégie possible. Le retour sur investissement ne sera qu’assez peu modifié : étant donné les prix des licences propriétaires, on a vu (en conférence PostgreSQL Europe à Amsterdam) des projets inclure un développement spécifique et voir son retour sur investissement passer de 2 mois à… 8 mois, ce qui reste inférieur à 1 an!
Alors, qu’attendez-vous pour évaluer les bénéfices que vous aurez à migrer vers PostgreSQL ?
La cinquième conférence annuelle "Prague PostgreSQL Developers Day", organisée pas le CSPUG (PUG Tchèque & Slovaque), aura lieu le 9 février 2012 à Prague. L'appel à conférenciers est lancé. Merci d'envoyer vos propositions, incluant le sujet, une estimation de la durée et vos coordonnées à l'adresse info CHEZ p2d2 POINT cz.
Les nouveautés des produits dérivés
Offres d'emplois autour de PostgreSQL en novembre
PostgreSQL Local
PostgreSQL dans les média
PostgreSQL Weekly News / les nouvelles hebdomadaires vous sont offertes cette semaine par David Fetter. Traduction par l'équipe PostgreSQLFr sous licence CC BY-NC-SA.
Proposez vos articles ou annonces avant dimanche 15:00 (heure du Pacifique). Merci de les envoyer en anglais à david (a) fetter.org, en allemand à pwn (a) pgug.de, en italien à pwn (a) itpug.org et en espagnol à pwn (a) arpug.com.ar.
(lien vers l'article original)
Revues de code
Correctifs appliqués
Tom Lane a poussé :
Heikki Linnakangas a poussé :
Robert Haas a poussé :
Peter Eisentraut a poussé :
Bruce Momjian a poussé :
Simon Riggs a poussé :
Michael Meskes a poussé :
Correctifs rejetés (à ce jour)
Correctifs en attente
Les nouveautés des produits dérivés
Offres d'emplois autour de PostgreSQL en novembre
PostgreSQL Local
PostgreSQL dans les média
PostgreSQL Weekly News / les nouvelles hebdomadaires vous sont offertes cette semaine par David Fetter. Traduction par l'équipe PostgreSQLFr sous licence CC BY-NC-SA.
Proposez vos articles ou annonces avant dimanche 15:00 (heure du Pacifique). Merci de les envoyer en anglais à david (a) fetter.org, en allemand à pwn (a) pgug.de, en italien à pwn (a) itpug.org et en espagnol à pwn (a) arpug.com.ar.
(lien vers l'article original)
Correctifs appliqués
Tom Lane a poussé :
Magnus Hagander a poussé :
Simon Riggs a poussé :
Bruce Momjian a poussé :
Peter Eisentraut a poussé :
Robert Haas a poussé :
Heikki Linnakangas a poussé :
Andrew Dunstan a poussé :
Alvaro Herrera a poussé :
Correctifs rejetés (à ce jour)
Correctifs en attente
L'appel à conférenciers est lancé pour la PostgreSQL Session #3, programmée le 2 février 2012 à Paris. La date limite de dépôt est le 30 novembre 2011 et les conférenciers sélectionnés seront contactés avant le 14 décembre. Les propositions (en français ou anglais) doivent être envoyées à call-for-paper AT postgresql-sessions DOT org. Plus d'informations sur : http://www.postgresql-sessions.org/en/3/
Les nouveautés des produits dérivés
Offres d'emplois autour de PostgreSQL en octobre
PostgreSQL Local
PostgreSQL dans les média
PostgreSQL Weekly News / les nouvelles hebdomadaires vous sont offertes cette semaine par David Fetter. Traduction par l'équipe PostgreSQLFr sous licence CC BY-NC-SA.
Proposez vos articles ou annonces avant dimanche 15:00 (heure du Pacifique). Merci de les envoyer en anglais à david (a) fetter.org, en allemand à pwn (a) pgug.de, en italien à pwn (a) itpug.org et en espagnol à pwn (a) arpug.com.ar.
(lien vers l'article original)
Revues de code
Correctifs appliqués
Magnus Hagander a poussé :
Alvaro Herrera a poussé :
Tom Lane a poussé :
Bruce Momjian a poussé :
Heikki Linnakangas a poussé :
Robert Haas a poussé :
Correctifs rejetés (à ce jour)
Correctifs en attente
Bonjour,
J’ ai constaté une petite coquille avec l’installation de postgresql 9.0.x avec Yum sur Centos (par exemple).
On a beau changer de port au niveau du postgresql.conf ça ne change en aucun cas le port d’écoute ![]()
Il faut aller dans le /etc/init.d/postresql-9.0 et modifier le PGPORT à la main.
Et il ne faut pas oublier qu’en cas de mise à jour le port par défaut (5432) reviendra dans le fichier de démarrage, donc à remodifier.
Voilà je voulais juste le signaler ^^
La conférence européenne à Amsterdam était un très bon évènement de la communauté, avec une organisation impeccable dans un hôtel accueillant. J'ai eu le plaisir d'y parler des extensions et de leur usage dans le cadre du développement applicatif « interne », sous le titre Extensions are good for business logic.
L'idée de ma présentation, que la plupart d'entre vous a loupé je suppose
(en tout cas je n'avais qu'une petite poignée de français dans la salle, et
j'espère avoir des lecteurs qui n'étaient pas à Amsterdam), l'idée est
d'utiliser les mécanismes offerts par les extensions afin de maintenir le
code PL que vous utilisez en production.
Il s'agit la plupart du temps de procédures qui implémentent une partie de la logique métier de vos applications, mais si proche des données que cela termine en base directement : c'est une bonne chose, en particulier depuis PostgreSQL 9.1. Cette version propose en effet une gestion assez complète des extensions.
Il s'agit de réaliser un empaquetage de vos procédures en suivant la
documentation en ligne et son chapitre
35.15. Empaqueter des objets dans une extension. Une fois cela fait, il est
alors possible de déployer votre ensemble de procédure stockée avec la
commande CREATE EXTENSION mesprocs;, et ensuite la commande psql \dx vous
permet de lister les extensions installées et leur numéro de version.
Les mises à jours sont également gérées avec une commande SQL dédiée, il
s'agit alors de ALTER EXTENSION mesprocs UPDATE [TO version];. Il suffit de
fournir des scripts intermédiaires nommés par exemple mesprocs--1.0--1.1.sql
et mesprocs--1.1--1.2.sql et PostgreSQL saura comment passer de 1.0 à 1.1.
Voilà, vous savez presque tout de ma présentation à Amsterdam et vous pouvez retrouver le reste sur le support proposé en début d'article. Bien sûr je n'ai pas reproduit ici les questions intéressantes qui m'ont été posées, une bonne partie d'entre elles sont venues enrichir ma liste de Noël pour les extensions. Si vous voulez être sûr de trouver cela sous votre sapin, cependant, le meilleur moyen est encore de m'en parler : sponsoriser les développement Open Source est une belle démarche :)
par dim@tapoueh.org (Dimitri Fontaine) le lundi 31 octobre 2011 à 13h22
Comme promis, voici la nouvelle version de pgsnap. Dans les nouveautés, la compatibilité avec PostgreSQL 9.1, un rapport sur les journaux de transactions et un autre sur les tailles d'index, la possibilité de trier tous les tableaux (merci jquery), sans parler de la possibilité d'ajouter automatiquement un répertoire contenant le rapport de toutes les bases de données.
Bref, du bon, mais rien de majeur non plus. La 0.8 devrait proposer plus de nouveaux rapports, et il est tout à fait possible qu'elle arrive rapidement (ie, avant la fin de l'année).
J'en ai profité pour faire une page wiki sur github qui récapitule quelques informations sur cet outil.
PGDay.SoCal est au programme de SCALE10X (exposition Linux dans le sud de la Californie) tenue au LAX Hilton Hotel de Los Angeles, le vendredi 20 janvier 2012. Veuillez envoyer vos propositions de conférences à pgday-submissions CHEZ googlegroups POINT com. https://sites.google.com/site/pgdayla/
Le programme de Postgres Brazil 2011 est en ligne : http://pgbr.postgresql.org.br/2011/programacao.en.php
Jim Mlodgenski présente "Visualizing PostgreSQL Data with Google Web Toolkit" (Visualisation de données PostgreSQL avec Google Web Toolkit) avec le NYCPUG le 25 octobre 2011 à 18h30. Détails et RSVP ci-dessous : http://www.nycpug.org/events/36991582/
Les nouveautés des produits dérivés
Offres d'emplois autour de PostgreSQL en octobre
PostgreSQL Local
PostgreSQL dans les média
PostgreSQL Weekly News / les nouvelles hebdomadaires vous sont offertes cette semaine par David Fetter. Traduction par l'équipe PostgreSQLFr sous licence CC BY-NC-SA.
Proposez vos articles ou annonces avant dimanche 15:00 (heure du Pacifique). Merci de les envoyer en anglais à david (a) fetter.org, en allemand à pwn (a) pgug.de, en italien à pwn (a) itpug.org et en espagnol à pwn (a) arpug.com.ar.
(lien vers l'article original)
Revues de code
Correctifs appliqués
Magnus Hagander a poussé :
Tom Lane a poussé :
Robert Haas a poussé :
Heikki Linnakangas a poussé :
Correctifs rejetés (à ce jour)
Correctifs en attente
Tout d'abord un grand merci aux personnes qui ont répondu à l'appel lancé en juin pour organiser une conférence dédiée à PostgreSQL en France et en 2012.
PostgreSQL Conference Europe 2011 vient de s'achever à Amsterdam et même si je n'étais pas présent cette année, les échos que j'en reçois confirment que ces conférences sont des moments essentiels pour la vie d'une communauté.
Bref après les PG Day France de 2008 et 2009, il est temps de relancer la machine !
La première réunion du groupe organisateur est prévue :
(Contactez moi si vous ne pouvez pas être présent ou si vous avez du mal à nous rejoindre sur IRC )
Participer à l'organisation d'une conférence est vraiment une superbe occasion d'entrer en contact avec la communauté PostgreSQL. En guise d'exemples, voici quelques taches à réaliser :
Pour l'instant, la date et le lieu ne sont pas fixés. On sait juste que ça se passera en France en 2012 Tout le reste est à inventer....
Par ailleurs, à toute fin utile précisons que :
a/ Cet évènement est soutenu par l'association PostgreSQLFr
b/ L'organisation de l’événement est ouverte aux individus et aux sociétés qui ne font pas partie de l'asso
c/ L'association est prête a engager des moyens financiers et administratifs pour aider à la réalisation de la conférence. Les éventuelles pertes seront supportées par l'asso. En contrepartie, les éventuels bénéfices seront gérés par l'asso. La trésorière de l'association pourra à tout moment opposer un veto à une dépense jugée inutile.
Vendredi a commencé assez difficilement : Gilles Darold à qui j'ai dû expliqué très rapidement et très mal l'enregistrement des personnes à l'accueil, pas de portable pour la conférence de Jean-Paul Argudo, et le portable de Luis Ochoa qui ne voulait pas fonctionner avec le rétro-projecteur... bref, la conférence donnée par Luis et moi-même a commencé un brin en retard et un peu sur les chapeaux de roue. Elle s'est néanmoins très bien passée. Bruce Momjian faisait partie de l'audience et a été impressionné par ce que Luis a été capable de faire en trois à quatre mois. Une personne lui avait posé une question mardi dernier, à savoir avait-on un outil libre capable de faire de la conception graphique de bases de données. Et il avait répondu non. Mais maintenant, il pourra répondre oui
Bref. Le public était plutôt restreint pour nous (environ 10 personnes) ainsi que pour Jean-Paul, mais les retours ont été très bons. Le reste du public était dans la salle principale où Simon Riggs parlait du futur de PostgreSQL. Et, à ma grande surprise, il a parlé de réplication bi-directionnelle (autrement dit du maître/maître). Oui. Miam 
Gevik devait être le responsable des conférences de la deuxième salle mais il tenait beaucoup à assister à la conférence de Greg Smith sur les benchmarks. J'ai donc pris son poste pour qu'il puisse aller écouter Greg. De mon côté, ça m'a permis d'assister à la conférence de Jehan-Guillaume de Rorthais et de Leonardo Augusto Sapiras. Ils ont parlé de l'ajout d'un système de plugins dans phpPgAdmin, travail effectué pendant le GSoC 2011 par Leonardo. Très sympa, et certainement des plugins très intéressants vont arriver rapidement (allez, rapidement, de tête, un database designer bien plus joli que celui de pgAdmin (oui, je suis jaloux) et pgpooladmin).
Ensuite, Michael Meskes a parlé de la possibilité de remplacer une base de données propriétaire par PostgreSQL. Vu son expérience avec Informix, Oracle et SQL Server, il a donné quelques informations très utiles et quelques arguments qui jouent clairement en la faveur de PostgreSQL. Personnellement, j'ai aussi été très content de rencontrer ce monsieur dont j'entends parler depuis... facilement dix ans, et que je n'avais encore jamais rencontré.
Concernant les autres conférences de ce matin, j'avais déjà vu celle de Magnus Hagander lors de char(11). Une excellente conférence qui ouvre les yeux sur les possibilités offertes par le protocole de réplication.
L'après-midi a été beaucoup plus calme. Elle a commencé avec trois conférences. Vu le manque d'audience, la conférence de Jean-Paul a été annulée. Il semble que les conférences en français n'ont pas marché du tout et il faudra éviter cette erreur l'année prochaine.
J'étais moi-même à la conférence de Stephen Frost. Très intéressante, elle passait sur tous les points qui concernent la recherche des requêtes lentes ainsi que leur correction. Simple et bien vu. Par un conférencier très à l'aise, et très rapide. La dernière conférence était donnée par Selena Deckelmann (« Managing terabytes »), que j'avais déjà vu grâce à une vidéo sur internet (les slides sont sur http://www.slideshare.net/selenamarie/managing-terabytes et la vidéo sur http://www.casttv.com/video/v9n1zxu/postgresql-screencasts-managing-terabytes-video ... désolé la vidéo que j'avais était meilleure mais je n'arrive pas à retrouver le lien). Une conférence plutôt intéressante.
Pour la fin, Ed Boyajian, CEO d'EDB, devait intervenir mais dû à un problème avec les douanes américaines, il n'a pas pu venir. Du coup, il a fait un petit discours via Skype pendant 10/15 minutes. Puis, Bruce Momjian a donné la conférence finale. Il a expliqué ce qu'il avait vu, entendu pendant ces quelques jours. Ce n'est rien de dire qu'il m'a de nouveau motivé à m'impliquer encore davantage dans cette communauté et je pense ne pas avoir été le seul 
La journée s'est terminée avec les remerciements du staff aux conférenciers et aux participants.
Que dire de plus. C'était une extraordinaire expérience, des journées formidables et j'espère que je serais là l'année prochaine pour en profiter de nouveau.
Je devais rester à l'accueil le matin mais Dave étant bizarrement aussi à l'accueil, j'en ai profité pour prendre des photos des conférenciers, ainsi que d'écouter un peu chaque conférence.
Cédric Villemain a fait une conférence en français sur Slony et Londiste. Il a pu ainsi annoncer la sortie de la dernière version de Slony, la 2.1, sortie survenue vers 2h du matin (heure locale) ce même jour. C'est de l'instantané
Étant une conférence en français à Amsterdam, il y a eu peu de participants malheureusement.
Pendant ce temps-là, Greg Smith donnait sa conférence sur le VACUUM. Grosse audience et encore un gros succès pour Greg.
Mais j'ai préféré aller voir la conférence de Poojan Kumar, de la société vmware pour en savoir plus sur leur offre dans le "cloud". J'avoue avoir été assez impressionné par leur système de clonage et de sauvegarde.
Les trois conférences suivantes étaient encore une fois très intéressantes :
Personnellement, je serais plutôt allé à la conférence de Heikki. Je n'ai pas non plus eu l'occasion de voir les autres conférences de cette matinée. J'ai entendu des commentaires très positifs sur la conférence d'Alexander Korotkov, un étudiant GSoC qui présentait le résultat de son travail sur la création rapide d'index GiST. Travail qui devrait d'ailleurs être incorporé à la version 9.2. Cette dernière semble de plus en plus fortement orienté performances.
L'après-midi a commencé avec une conférence de Selena. Gros succès, impossible de fermer la porte de sa salle, les gens préféraient rester assis par terre, y compris à la porte pour l'écouter. Impressionnant 
Gianni Ciolli a eu aussi beaucoup de monde pour sa conférence sur les requêtes CTE en écriture.
Jonathan Katz a présenté l'écriture d'extensions Django pour PostgreSQL, qui a eu malheureusement moins de succès, alors que le contenu est vraiment intéressant.
Ensuite a eu lieu ma propre conférence. 50 minutes sur les vues statistiques et sur ce qu'on peut en faire. J'ai eu entre 20 et 30 personnes, peut-être un peu plus. Les gens avaient l'air intéressé, notamment par les graphiques et le moyen d'y arriver. J'ai fini bien en avance, ce qui a permis quelques questions/réponses suivies d'une démo sur l'utilisation de la vue pg_locks (un peu hors sujet mais intéressant malgré tout).
Après ma conférence, j'ai eu l'occasion de discuter longuement avec Pavel Gollub, développeur principal des outils PostgreSQL proposés par microolap. Notamment, il a fait une démo très impressionnante de Database Designer. C'est vraiment le grand avantage de ce genre d'événements : rencontrer les gens qui créent et qui utilisent PostgreSQL. C'est très informatif, pratiquement plus que les conférences elles-mêmes.
La dernière conférence était les « Lightning talks ». C'est un ensemble de petites conférences. Chaque personne intéressé a cinq minutes maximum pour présenter une idée, un concept, un projet.
Cela peut ne pas être sérieux du tout, comme celle réalisée par Selena, ou au contraire très technique, ce qu'a fait Hans-Juergen.
Après cela, il a fallu attendre 19h pour aller à la soirée sponsorisée par Heroku : beaucoup de boissons, beaucoup de snacks et encore plus de discussions. Merci Heroku 
Première journée des conférences standards, donc gros rush à l'enregistrement. Néanmoins, cela se passe bien. Le fait d'avoir déjà enregistré les personnes venu hier a certainement bien aidé.
Magnus Hagander a fait son discours de bienvenue, puis a introduit Ram Mohan de la société Affilias. Ram venait faire la conférence d'ouverture de pgconf.eu 2011. C'est un exercice difficile qui demande beaucoup de travail et je dois dire que Ram s'en est très bien sorti. C'est intéressant, factuel et en même temps motivant. Motivant pour utiliser PostgreSQL mais aussi pour participer à la communauté.
Après cette conférence et la pause-café, les conférences ont commencé. Difficile de ne pas trouver une conférence intéressante quand trois salles proposent une conférence chacune pratiquement toutes les heures. En fait, il a surtout été reproché que le choix était difficile à cause de la qualité des conférences et du fait que beaucoup se déroulaient en parallèle. C'est un problème bon à avoir car cela indique que nous ne nous sommes pas trompés dans le choix des conférences.
Malheureusement, faisant parti des organisateurs, je n'ai pas pu voir beaucoup de conférences entières. Je me suis baladé le matin entre les différentes salles de conférences pour prendre des photos. Magnus a eu beaucoup de succès avec sa conférence sur les nouveautés de la version 9.1 : beaucoup d'informations car beaucoup de nouvelles fonctionnalités, avec le point de vue d'un des développeurs majeurs de PostgreSQL.
Dave Page a d'ailleurs été dans le détail d'une de ses nouvelles fonctionnalités : SQL/MED.
J'avais déjà vu cette conférence, elle est vraiment bien pour comprendre comment implémenter un Foreign Data Wrapper. La conférence de Vincent Picavet sur PostGIS a aussi été bien suivie : PostGIS est vraiment une extension importante dans le monde de PostgreSQL.
Quant à Gianni Ciolli, il a osé aborder les fonctions de fenêtrage avec sa bonne humeur habituelle. Difficile quand il s'agit d'un sujet aussi complexe que celui-là.
L'après-midi, étant responsable d'une salle de conférences, j'ai pu voir les conférences qui s'y déroulaient entièrement. Gilles Darold a ouvert le bal avec une conférence sur ora2pg, malheureusement en français, ce qui a fait que peu de personnes y ont assisté. Pourtant, beaucoup voulaient venir mais une fois qu'ils ont compris que c'était en français seulement, ça a réduit nettement l'audience.
Gilles a expliqué l'historique du projet, les dernières fonctionnalités, les problèmes qu'il a pu rencontré, et plein d'autres choses encore. Ensuite, nous avons eu Marc Balmer.
Il a montré un exemple d'utilisation du mécanisme LISTEN/NOTIFY de PostgreSQL. Se faisant, il a démontré l'intérêt de ce mécanisme très particulier. C'était très convaincant. Enfin, Stephen Frost est venu parler de l'organisation de la revue de patchs. Stephen participe beaucoup au développement de PostgreSQL, il a notamment beaucoup contribué à l'intégration de la gestion des rôles. Du coup, sa vision du développement aidait bien à appréhender le besoin de revue de patchs, y compris par des personnes ayant une connaissance faible du langage C. Comme il le disait, mieux vaut que plusieurs personnes relisent les patchs, ça permet de détecter plus rapidement les éventuels bugs qui s'y trouvent.
Du coup, je n'ai pas vu du tout les autres conférences. Bruce Momjian a expliqué l'optimiseur de requêtes. J'avais déjà vu cette conférence lors d'un autre événement et le succès qu'il a eu cette fois-ci ne m'étonne pas du tout. Greg Smith et Simon Riggs ont parlé de réplication. Là-aussi, grosse audience, gros succès. Je serais bien allé à la conférence de Steve Singer (« Troubleshooting Slony »), ainsi qu'à celle de Stefan Kaltenbrunner (« Metering the smart way, a smart grid for the datacenter »). Je n'ai jamais eu l'occasion de les voir et j'en ai entendu beaucoup de bien.
La soirée a commencé à l'hôtel. Dalibo a sponsorisé une première heure de boissons et snacks gratuits, et OpenSCG a sponsorisé une deuxième heure. Après ça, nous sommes partis avec les personnes de Skype à la recherche d'un restaurant.
Cette journée est une journée consacrée aux mini-formations. Bruce Momjian a fait une journée sur l'administration de PostgreSQL. Greg Smith a fait lui-aussi une journée entière sur les performances. Enfin, Magnus Hagander et moi-même avons fait une demi-journée chacun sur la réplication. Magnus a présenté la réplication interne de PostgreSQL et je me suis occupé de la réplication proposée par Slony. Les formations les plus populaires étaient évidemment celles de Bruce et de Greg mais je suis assez content de voir que quelques personnes étaient intéressées par Slony.
Ma formation s'est bien passée. C'était la première fois que j'en faisais une en anglais mais après un petit stress inévitable, ça s'est bien mieux passé que ce que je craignais.
Voilà donc une question intéressante, comment se comporte PostgreSQL face à un système de fichier plein ? Un peu d'expérimentation est nécessaire pour se rassurer...
On crée deux systèmes de fichiers de faible taille pour les tests. Le premier stockera PGDATA, ainsi qu'une base de données nommée db_data. Le second sera le tablesapce ts1, dans lequel on créera une base de données db_ts1.
L'objectif est de montrer que seules les transactions modifiant des objets stockés sur des systèmes de fichier plein sont affectées, c'est pourquoi on a besoin de plusieurs tablespaces
Les binaires se trouvent dans /home/pgsql/postgresql-9.0.4, PGDATA dans /home/pgsql/postgresql-9.0.4/data, et le tablespace dans /home/pgsql/postgresql-9.0.4/ts1. On a donc monté et donné la propriété des deux filesystèmes à orgrim, que fera tourner PostgreSQL :
# df -h ... /dev/mapper/sys-pg1 504M 54M 425M 12% /home/pgsql/postgresql-9.0.4/data /dev/mapper/sys-pg2 504M 17M 462M 4% /home/pgsql/postgresql-9.0.4/ts1 ... # cd /home/pgsql/postgresql-9.0.4/ # chown orgrim: data ts1 # chmod 700 data ts1
Le cluster est préparé avec l'environnement suivant :
$ env | grep PG PGPORT=5904 PGDATABASE=postgres PGDATA=/home/pgsql/postgresql-9.0.4/data PATH=/home/pgsql/postgresql-9.0.4/bin:$PATH
On lance donc initdb, puis on crée les bases avec le tablespace :
$ initdb $ psql psql (9.0.4) Type "help" for help. postgres=# CREATE DATABASE db_data; CREATE DATABASE postgres=# CREATE TABLESPACE ts1 LOCATION '/home/pgsql/postgresql-9.0.4/ts1'; CREATE TABLESPACE postgres=# CREATE DATABASE db_ts1 TABLESPACE ts1; CREATE DATABASE
Ensuite, on se connecte à la base de données db_ts1 et on y
crée une base qui permettra de remplir le tablespace ts1 :
$ while ((1)); do psql -c "INSERT INTO t SELECT generate_series(1, 1000) AS i;" db_ts1; done
Au bout, d'un moment le système de fichier du tablespace est plein et tout requête générant des écritures sort en erreur avec un message de cette forme :
ERROR: could not extend file "pg_tblspc/16385/PG_9.0_201008051/16386/16390": wrote only 4096 of 8192 bytes at block 58438 HINT: Check free disk space.
Ensuite, on essaye avec le répertoire PGDATA, on crée donc une table dans la base db_data :
$ psql db_data psql (9.0.4) Type "help" for help. db_data=# CREATE TABLE t (i int); CREATE TABLE
De la même façon, on remplit cette table jusqu'à épuisement de l'espace libre :
$ while ((1)); do psql -c "INSERT INTO t SELECT generate_series(1, 1000) AS i;" db_data; done
Résultat, les requêtes sortent en erreur de la même façon. On a peut-être de la chance ici, le filesystem contenant pg_xlog, les problèmes pourraient être pis.
Il est également possible de remplir le système de fichiers de journaux de transactions, ce qui est problématique du fait que chaque transaction est écrite ici tout tablespace confondu. On vide donc les deux bases :
$ psql db_ts1 psql (9.0.4) Type "help" for help. db_ts1=# TRUNCATE t; TRUNCATE TABLE $ psql db_data psql (9.0.4) Type "help" for help. db_data=# TRUNCATE t; TRUNCATE TABLE
Et on place le paramètre checkpoint_segments à 300, valeur
démesurée par rapport à la place disponible dans PGDATA.
Après un reload, on refait alors le test de remplissage de la base db_ts1, qui
assure que les journaux de transactions seuls remplissent PGDATA.
Le serveur PostgreSQL s'arrête parce qu'il ne peut écrire le journal de transaction :
PANIC: could not write to file "pg_xlog/xlogtemp.8795": No space left on device STATEMENT: INSERT INTO t SELECT generate_series(1, 1000) AS i; LOG: server process (PID 8795) was terminated by signal 6: Aborted LOG: terminating any other active server processes WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. HINT: In a moment you should be able to reconnect to the database and repeat your command. LOG: all server processes terminated; reinitializing
Il redémarre illico, mais le problème persiste :
FATAL: the database system is in recovery mode LOG: database system was interrupted; last known up at 2011-10-12 00:01:40 CEST LOG: database system was not properly shut down; automatic recovery in progress LOG: consistent recovery state reached at 0/5FDB7480 LOG: redo starts at 0/5AA57D68 LOG: could not open file "pg_xlog/000000010000000000000074" (log file 0, segment 116): No such file or directory LOG: redo done at 0/73FFFF90 LOG: last completed transaction was at log time 2011-10-12 00:05:11.710639+02 PANIC: could not write to file "pg_xlog/xlogtemp.8797": No space left on device LOG: startup process (PID 8797) was terminated by signal 6: Aborted LOG: aborting startup due to startup process failure
Le seul moyen de se sortir de cette situation est d'utiliser les
5% d'espace libre du filesystème réservés au super utilisateur, de baisser la valeur de checkpoint_segments à une valeur évitant le filesystem full, les checkpoints successif supprimeront les fichiers en trop.
Lorsqu'on a plus besoin de 5% réservés, il ne faut pas oublier de remettre la réservation.
Enfin, ce cas le plus critique peut arriver assez facilement lorsqu'on a de l'archivage, si le serveur ne peut plus archiver les fichiers WAL, alors il les conserve, un filesystem full sur un espace d'archivage peut donc être transmis au serveur...
Les nouveautés des produits dérivés
Offres d'emplois autour de PostgreSQL en octobre
PostgreSQL Local
PostgreSQL dans les média
PostgreSQL Weekly News / les nouvelles hebdomadaires vous sont offertes cette semaine par David Fetter. Traduction par l'équipe PostgreSQLFr sous licence CC BY-NC-SA.
Proposez vos articles ou annonces avant dimanche 15:00 (heure du Pacifique). Merci de les envoyer en anglais à david (a) fetter.org, en allemand à pwn (a) pgug.de, en italien à pwn (a) itpug.org et en espagnol à pwn (a) arpug.com.ar.
(lien vers l'article original)
Revues de code
Correctifs appliqués
Bruce Momjian a poussé :
Robert Haas a poussé :
Tom Lane a poussé :
Correctifs rejetés (à ce jour)
Correctifs en attente
Après 3h30 de voyage en train, nous sommes enfin arrivés à Amsterdam pour les quatre jours de conférences sur PostgreSQL organisés par PostgreSQL Europe.
Ça fait maintenant un an qu'une dizaine de personnes travaillent, semaine après semaine, sur cet événement. Faisant parti de ces dix personnes, il est très plaisant d'en voir maintenant le résultat.
Dave Page et Magnus Hagander sont déjà à l'hôtel quand nous y arrivons. Nous les rejoignons rapidement pour leur dire bonjour, puis partons visiter la ville de notre côté pendant deux petites heures.
Au retour, il a fallu préparer les sacs que nous donnerons le lendemain aux participants, ainsi que les badges. Le travail s'est terminé à 20h. Nous sommes tous partis manger dans le centre-ville d'Amsterdam, et nous avons terminé la soirée au bar de l'hôtel.
La "PostgreSQL Conference Europe 2011" se tiendra à Amsterdam, du 18 au 21 octobre. Les inscriptions sont encore ouvertes : http://2011.pgconf.eu/registration/
Les nouveautés des produits dérivés
Offres d'emplois autour de PostgreSQL en octobre
PostgreSQL Local
PostgreSQL dans les média
PostgreSQL Weekly News / les nouvelles hebdomadaires vous sont offertes cette semaine par David Fetter. Traduction par l'équipe PostgreSQLFr sous licence CC BY-NC-SA.
Proposez vos articles ou annonces avant dimanche 15:00 (heure du Pacifique). Merci de les envoyer en anglais à david (a) fetter.org, en allemand à pwn (a) pgug.de, en italien à pwn (a) itpug.org et en espagnol à pwn (a) arpug.com.ar.
(lien vers l'article original)
Revues de code
Correctifs appliqués
Tom Lane a poussé :
Alvaro Herrera a poussé :
Bruce Momjian a poussé :
Heikki Linnakangas a poussé :
Robert Haas a poussé :
Magnus Hagander a poussé :
Correctifs rejetés (à ce jour)
Correctifs en attente
La conférence PostgreSQL annuelle en Europe a lieu la semaine prochaine à Amsterdam, et j'espère que vous avez déjà vos billets, car cette édition s'annonce comme un très bon millésime !
Je présenterai donc comment utiliser les extensions, le titre en anglais est Extensions are good for business logic, et l'idée est de voir comment exploiter les extensions afin de mieux gérer vos mises à jours en bases de données.
Le cycle de vie des bases de données en production inclue souvent
l'utilisation d'une base de développement où le schéma évolue au rythme des
besoins des développeurs, et de temps en temps on consolide une partie de
ces modifications (dans des rollouts, scripts contenant principalement des
DDL) afin de les déployer en production — si possible avec une étape
intermédiaire en préproduction, tout de même.
Savoir ce qui est déployé en développement et comment en retirer le script à jouer en production peut être parfois fastidieu. Quand ce n'est pas le cas, c'est que le travail a été fait en amont, ce qui est le signe d'une bonne organisation, avec les surcoûts que l'on peut imaginer.
Les extensions telles que présentes dans PostgreSQL 9.1 vous permettent de mieux gérer ce genre de cas, en optimisant le surcoût : il ne disparaît pas, mais devient opérationnel plutôt que de rester une charge d'organisation.
Allez, je vous laisse maintenant, je dois me préparer pour la conférence :)
par dim@tapoueh.org (Dimitri Fontaine) le lundi 10 octobre 2011 à 08h35
Inscriptions spéciales "lèves-tôts" (pas cher ! pas cher !) disponibles pour le PGDay.IT : http://blog.2ndquadrant.com/en/2011/09/pgday-it-2011-early-bird-registrations-open.html
La liste des conférenciers pour le PGBR2011 a été publiée : http://pgbr.postgresql.org.br/2011/palestrantes.en.php
Les nouveautés des produits dérivés
PostgreSQL Local
PostgreSQL dans les média
PostgreSQL Weekly News / les nouvelles hebdomadaires vous sont offertes cette semaine par David Fetter. Traduction par l'équipe PostgreSQLFr sous licence CC BY-NC-SA.
Proposez vos articles ou annonces avant dimanche 15:00 (heure du Pacifique). Merci de les envoyer en anglais à david (a) fetter.org, en allemand à pwn (a) pgug.de, en italien à pwn (a) itpug.org et en espagnol à pwn (a) arpug.com.ar.
(lien vers l'article original)
Revues de code
Correctifs appliqués
Tom Lane a poussé :
Robert Haas a poussé :
Alvaro Herrera a poussé :
Bruce Momjian a poussé :
Correctifs rejetés (à ce jour)
Correctifs en attente
Les MAJ de sécurité 9.1.1, 9.0.5, 8.4.9, 8.3.16 et 8.2.22 sont disponibles. Installez-les dès que possible si vous êtes concernés. Détails ci-après : http://www.postgresql.org/about/news.1355
[ndt: annonce détaillée, en français : http://blog.postgresql.fr/index.php?post/2011/09/26/Nouvelles-versions-mineures]
Les nouveautés des produits dérivés
Offres d'emplois autour de PostgreSQL en septembre
PostgreSQL Local
PostgreSQL dans les média
PostgreSQL Weekly News / les nouvelles hebdomadaires vous sont offertes cette semaine par David Fetter. Traduction par l'équipe PostgreSQLFr sous licence CC BY-NC-SA.
Proposez vos articles ou annonces avant dimanche 15:00 (heure du Pacifique). Merci de les envoyer en anglais à david (a) fetter.org, en allemand à pwn (a) pgug.de, en italien à pwn (a) itpug.org et en espagnol à pwn (a) arpug.com.ar.
(lien vers l'article original)
Correctifs appliqués
Tom Lane a poussé :
Robert Haas a poussé :
Peter Eisentraut a poussé :
Simon Riggs a poussé :
Magnus Hagander a poussé :
Bruce Momjian a poussé :
Correctifs rejetés (à ce jour)
Correctifs en attente