Trucs et astuces pour naviguer dans la communauté PostgreSQL

Ce blog concerne la communauté PostgreSQL, son fonctionnement et la meilleure façon de s'y retrouver. Notez qu'il ne s'agit que d'un aperçu... il y a beaucoup de documentation existante.

Présentation de la communauté, fonctionnement du développement

PostgreSQL est développé et maintenu par un réseau dispersé dans le monde de bénévoles hautement qualifiés passionnés par l'informatique de bases de données relationnelles, appelé PostgreSQL Global Development Group. Une poignée de membres de l'équipe principale s'occupent ensemble de responsabilités particulières telles que la coordination des activités de publication, les communications internes spéciales, les annonces de politique, la supervision des privilèges d'engagement et de l'infrastructure d'hébergement, les questions disciplinaires et autres questions de leadership, ainsi que la responsabilité individuelle des domaines de contribution au codage, au développement et à la maintenance. . Une quarantaine de personnes supplémentaires sont considérées comme des contributeurs majeurs qui ont, comme leur nom l'indique, entrepris des activités de développement ou de maintenance complètes pour des fonctionnalités de base de code importantes ou des projets étroitement liés. Et plusieurs dizaines d'autres personnes apportent activement diverses autres contributions. Outre les contributeurs actifs, une longue liste d'anciens contributeurs est reconnue pour son travail sur le projet. Ce sont les compétences et les normes élevées de cette équipe qui ont abouti à l'ensemble de fonctionnalités riches et robustes de PostgreSQL.

De nombreux contributeurs ont des emplois à temps plein directement liés à PostgreSQL ou à d'autres logiciels Open Source, et le soutien enthousiaste de leurs employeurs rend possible leur engagement durable avec la communauté PostgreSQL.

Les personnes qui contribuent se coordonnent à l'aide d'outils de collaboration tels que Internet Relay Chat (irc://irc.freenode.net/PostgreSQL) et les listes de diffusion de la communauté PostgreSQL (https://www.PostgreSQL.org/community/lists). Si vous êtes nouveau sur IRC ou sur les listes de diffusion, faites un effort spécifique pour lire l'étiquette et les protocoles (un bon article apparaît sur https://fedoramagazine.org/beginners-guide-irc/), et après votre adhésion, dépensez un peu de temps pour écouter les conversations en cours et rechercher dans les archives des questions similaires précédentes avant de vous lancer dans vos propres problèmes.

Notez que l'équipe n'est pas statique :n'importe qui peut devenir contributeur en, eh bien, en contribuant... mais votre contribution devra répondre à ces mêmes normes élevées !

L'équipe maintient une page Wiki (https://wiki.postgresql.org/) qui, parmi de nombreuses informations très détaillées et utiles comme des articles, des tutoriels, des extraits de code et plus encore, présente une liste TODO des bogues PostgreSQL et des demandes de fonctionnalités et d'autres domaines où des efforts pourraient être nécessaires. Si vous voulez faire partie de l'équipe, c'est un bon endroit à parcourir. Les éléments ne sont ajoutés qu'après une discussion approfondie sur la liste de diffusion des développeurs.

La communauté suit un processus, visualisé comme les étapes de la figure 1.

C'est-à-dire que la valeur de toute nouvelle implémentation de code non triviale devrait d'abord être discutée et jugée (par consensus) souhaitable. Ensuite, on investit dans le design :conception de l'interface, de la syntaxe, de la sémantique et des comportements, et prise en compte des problèmes de rétrocompatibilité. Vous souhaitez obtenir l'adhésion de la communauté des développeurs sur le problème à résoudre et sur ce que cette implémentation accomplira. Vous ne voulez certainement PAS partir et développer quelque chose dans le vide par vous-même. Il y a littéralement des décennies d'expérience collective de très haute qualité incarnées dans l'équipe, et vous voulez, et ils s'attendent à ce que les idées soient examinées tôt.

Le code source PostgreSQL est stocké et géré à l'aide du système de contrôle de version Git, de sorte qu'une copie locale peut être extraite de https://git.postgresql.org/ pour commencer l'implémentation. Notez que pour une maintenabilité durable, les correctifs doivent se fondre dans le code environnant et suivre les conventions de codage établies (http://developer.postgresql.org/pgdocs/postgres/source.html), c'est donc une bonne idée d'étudier tout code similaire sections pour apprendre et imiter les conventions. Généralement, le format standard de style BSD est utilisé. Assurez-vous également de mettre à jour la documentation, le cas échéant.

Les tests impliquent d'abord de s'assurer que les tests de régression existants réussissent et qu'il n'y a pas d'avertissements du compilateur, mais également d'ajouter de nouveaux tests correspondants pour tester la ou les fonctionnalités nouvellement implémentées.

Lorsque l'implémentation de la nouvelle fonctionnalité dans votre référentiel local est terminée, utilisez la fonctionnalité Git diff pour créer un correctif. Les correctifs sont soumis par e-mail à la liste de diffusion pgsql-hackers pour examen et commentaires, mais vous n'avez pas à attendre que votre travail soit terminé… une pratique intelligente consisterait à demander des commentaires progressivement. La page Wiki décrit les attentes quant au format et au contexte explicatif utile et comment montrer du respect pour le temps du réviseur de code.

Les principaux développeurs planifient périodiquement des fêtes de validation, au cours desquelles tous les correctifs non appliqués accumulés sont ajoutés au référentiel de code source par les committers autorisés. En tant que contributeur, votre code aura fait l'objet d'un examen rigoureux et vos propres compétences de développeur en seront probablement les meilleures. Pour rendre la pareille, on s'attend à ce que vous consacriez du temps à l'examen des correctifs des autres.

Les meilleurs sites Web pour obtenir des informations ou apprendre PostgreSQL

Les quelques outils dont vous ne pouvez pas vous passer

Les outils de ligne de commande fondamentaux pour travailler avec une base de données PostgreSQL font partie de la distribution normale. Le cheval de bataille est l'utilitaire de ligne de commande psql, qui fournit une interface interactive avec de nombreuses fonctionnalités pour interroger, afficher et modifier les métadonnées de la base de données, ainsi que pour exécuter des instructions de définition de données (DDL) et de manipulation de données (DML).

Parmi les autres utilitaires inclus, citons pg_basebackup pour établir une ligne de base pour la sauvegarde basée sur la réplication, pg_dump pour extraire une base de données dans un fichier de script ou un autre fichier d'archive, pg_restore pour restaurer à partir d'une archive pg_dump, etc. Tous ces outils ont d'excellentes pages de manuel et sont détaillés dans la documentation standard et de nombreux didacticiels en ligne.

pgAdmin est un outil d'interface utilisateur graphique très populaire qui fournit des fonctionnalités similaires à l'utilitaire de ligne de commande psql, mais avec la commodité du pointer-cliquer. La figure 2 montre une capture d'écran de pgAdmin III. Sur la gauche se trouve un panneau affichant tous les objets de base de données du cluster sur le serveur hôte connecté. Vous pouvez explorer la structure pour répertorier toutes les bases de données, schémas, tables, vues, fonctions, etc., et même ouvrir des tables et des vues pour examiner les données contenues. Pour chaque objet, l'outil créera le SQL DML pour supprimer et recréer l'objet également, comme indiqué dans le panneau inférieur droit. C'est un moyen pratique d'apporter des modifications pendant le développement de la base de données.

Deux de mes outils préférés pour les équipes de développeurs d'applications sont Sqitch (http://sqitch.org/), pour le contrôle des modifications de base de données, et pgTAP (http://pgtap.org/). Sqitch permet une gestion autonome des changements et un développement itératif au moyen de scripts écrits dans le dialecte SQL natif de votre implémentation, pas seulement PostgreSQL. Pour chaque modification de conception de base de données, vous écrivez trois scripts :un pour déployer la modification, un pour annuler la modification au cas où il serait nécessaire de revenir à une version précédente, et un pour vérifier ou tester la modification. Les scripts et les fichiers associés peuvent être conservés dans votre système de contrôle de révision juste à côté de votre code d'application. PgTAP est un framework de test qui inclut une suite de fonctionnalités pour vérifier l'intégrité de la base de données. Tous les scripts pgTAP sont également des fichiers de texte brut conformes aux processus normaux de gestion des révisions et de contrôle des modifications. Une fois que j'ai commencé à utiliser ces deux outils, j'ai eu du mal à imaginer travailler à nouveau sur des bases de données sans.

Conseils et astuces

La liste de diffusion générale PostgreSQL est la plus active des différentes listes communautaires et est la principale interface communautaire pour une assistance gratuite aux utilisateurs. Un assez large éventail de questions apparaît sur cette liste, générant parfois de longs allers-retours, mais obtenant le plus souvent des réponses rapides, informatives et précises.

Lorsque vous postez une question liée à l'utilisation de PostgreSQL, vous souhaitez généralement toujours inclure des informations générales, notamment la version de PostgreSQL que vous utilisez (répertoriée par l'outil de ligne de commande psql avec "psql --version"), le système d'exploitation sur lequel le serveur est en cours d'exécution, puis peut-être une description de l'environnement d'exploitation, par exemple s'il peut être principalement en lecture ou en écriture, le nombre typique d'utilisateurs et les problèmes de concurrence, les modifications que vous avez apportées à la configuration du serveur par défaut (c'est-à-dire pg_hba.conf et postgresql.conf), etc. Souvent, une description de ce que vous essayez d'accomplir est utile, plutôt qu'une analogie obtuse, car vous pourriez bien recevoir des suggestions d'amélioration auxquelles vous n'aviez même pas pensé par vous-même. De plus, vous obtiendrez la meilleure réponse si vous incluez des données DDL, DML et des exemples de données réels illustrant le problème et aidant les autres à recréer ce que vous voyez -- oui, les gens exécuteront réellement votre exemple de code et travailleront avec vous.

De plus, si vous demandez comment améliorer les performances des requêtes, vous voudrez fournir le plan de requête, c'est-à-dire la sortie EXPLAIN. Ceci est généré en exécutant votre requête sans modification, sauf pour la préfixer littéralement avec le mot "EXPLAIN", comme illustré à la figure 3 dans l'outil pgAdmin ou l'utilitaire de ligne de commande psql.

Sous EXPLAIN, au lieu d'exécuter réellement la requête, le serveur renvoie le plan de requête, qui répertorie la sortie détaillée de la façon dont la requête sera exécutée, y compris les index qui seront utilisés pour optimiser l'accès aux données, où les balayages de table peuvent se produire et les estimations de la le coût et la quantité de données impliquées à chaque étape. Le type d'aide que vous obtiendrez des praticiens expérimentés surveillant la liste de diffusion peut identifier les problèmes et aider à suggérer d'éventuels nouveaux index ou modifications des critères de filtrage ou de jointure.

Enfin, lorsque vous participez à des discussions sur une liste de diffusion, vous devez garder à l'esprit deux choses importantes.

Tout d'abord, le serveur de liste de diffusion est configuré pour envoyer des messages configurés de sorte que lorsque vous répondez, votre logiciel de messagerie ne répond par défaut qu'à l'auteur du message d'origine. Pour être sûr que votre message ira dans la liste, vous devez utiliser la fonction "répondre à tous" de votre logiciel de messagerie, qui inclura alors à la fois l'auteur du message et l'adresse de la liste.

Deuxièmement, la convention sur les listes de diffusion PostgreSQL est de répondre en ligne et de NE PAS TOP POSTER. Ce dernier point est une convention de longue date dans cette communauté, et pour de nombreux nouveaux arrivants, cela semble assez inhabituel pour que les remontrances douces soient très courantes. Les opinions varient sur la quantité du message original à retenir pour le contexte dans votre réponse. Certaines personnes s'irritent de la croissance parfois difficile de la taille du message lorsque l'intégralité du message original est conservée dans de nombreuses discussions en va-et-vient. Personnellement, j'aime supprimer tout ce qui n'est pas pertinent à ce à quoi je réponds spécifiquement afin de garder le message concis et ciblé. Gardez simplement à l'esprit qu'il y a des décennies d'historique de listes de diffusion conservées en ligne pour la documentation historique et les recherches futures, donc la conservation du contexte et du flux EST considérée comme très importante.

Cet article vous aide à démarrer, maintenant allez-y et plongez !