Technique | FAQ PostgreSQL

Par Guillaume Lelarge le 22/07/2004 - 21:57

Foire Aux Questions (FAQ) pour PostgreSQL

Dernière mise à jour : vendredi 11 juillet
2004 23:58:24

Mainteneur actuel : Bruce Momjian (pgman@candle.pha.pa.us)

Traducteurs :Laurent Martelli, Vincent Veyron, Emmanuel Seyman.

Relecteur :Guillaume Lelarge.

La plus récente version de ce document est disponible sur

http://www.postgresql.org/docs/faq/
(Mise à jour 22 mars 2006... il y avait un 404, désolé)

---

Questions générales

1.1) Qu'est ce que PostgreSQL ? Comment le
prononcer ?

1.2) Quelle est la licence de
PostgreSQL ?
1.3) Sous quels environnements Unix PostgreSQL
tourne-t-il ?
1.4) Sous quels environnements non-Unix
PostgreSQL tourne-t-il ?
1.5) Où puis-je me procurer
PostgreSQL ?

1.6) Où puis-je obtenir du
support ?
1.7) Quelle est la dernière
version ?
1.8) Quelle documentation est
disponible ?
1.9) Comment savoir quels sont les bogues connus
ou les fonctionnalités manquantes ?

1.10) Comment puis-je apprendre le
SQL ?
1.11) PostgreSQL est-il compatible an
2000 ?
1.12) Comment puis-je rejoindre l'équipe
de développement ?
1.13) Comment dois-je soumettre un rapport de
bogue ?

1.14) Comment PostgreSQL se compare-t'il
à d'autres SGBD ?
1.15) Comment puis-je aider
financièrement PostgreSQL ?

Questions sur le client utilisateur

2.1) Y a-t-il des pilotes ODBC

pour PostgreSQL ?
2.2) Quels outils sont disponibles pour utiliser
PostgreSQL avec des pages Web ?
2.3) PostgreSQL a-t-il une interface
graphique ?
2.4) Quels langages sont disponibles pour
communiquer avec PostgreSQL ?

Questions administratives

3.1) Comment installer PostgreSQL ailleurs que
sous /usr/local/pgsql ?
3.2) Quand je lance postmaster, j'obtiens
un Bad System Call ou un message core dumped.
Pourquoi ?
3.3) Quand je lance postmaster, j'obtiens
des erreurs IpcMemoryCreate. Pourquoi ?

3.4) Quand je lance postmaster, j'obtiens
des erreurs IpcSemaphoreCreate. Pourquoi ?
3.5) Comment contrôler les connexions
d'autres machines ?
3.6) Comment règler le moteur de la base
de données pour de meilleures performances ?

3.7) Quelles fonctionalités de
déboguage sont disponibles ?
3.8) Pourquoi est-ce que j'obtiens des messages
Sorry, too many clients quand je me connecte ?
3.9) Que contient le répertoire
pgsql_tmp ?

3.10) Pourquoi ai-je besoin de faire une
sauvegarde des bases et de restaurer pour mettre a jour les
versions de PostgreSQL ?
3.11) Quels matériels dois-je
utiliser ?

Questions fonctionnelles

4.1) Quelle est la différence entre
curseur binaire et curseur normal ?
4.2) Comment faire un SELECT

seulement sur les premières lignes d'une
requête ? Sur une ligne aléatoire ?
4.3) Comment obtenir une liste des tables ou
d'autres choses que je vois dans psql ?
4.4) Comment supprime-t-on une colonne d'une
table, ou comment change-t-on son type de
données ?

4.5) Quelle est la taille maximale pour une
ligne, une table et une base de données ?
4.6) Combien d'espace disque faut-il pour
stocker les données d'un fichier texte typique ?
4.7) Comment puis-je savoir quels index, tables,
bases de données et utilisateurs sont
définis ?
4.8) Mes requêtes sont lentes ou ne font
pas usage des index. Pourquoi ?

4.9) Comment puis-je savoir si l'optimiseur
évalue mes requêtes ?
4.10) Qu'est-ce qu'un index R-tree ?
4.11) Qu'est-ce que l'optimiseur
génétique de requêtes ?

4.12) Comment puis-je réaliser des
recherches par des expressions rationnelles ainsi que des
recherches non sensibles à la casse ? Comment puis-je
utiliser un index lors de recherches non sensibles à la
casse ?
4.13) Comment puis-je détecter si un
champ est NULL dans une requête ?

4.14) Quelle sont les différences entre
les nombreux types de caractères ?
4.15.1) Comment puis-je créer un champ
série, c'est-à-dire s'incrémentant
automatiquement ?
4.15.2) Comment puis-je obtenir la valeur
d'un SERIAL suite à une
insertion ?

4.15.3) Est-ce que currval() et
nextval() n'amènent pas des problèmes lorsque
plusieurs utilisateurs les lancent en même temps ?
4.15.4) Pourquoi mes numéros de
séquences ne sont pas ré-utilisés lors d'une
annulation de transaction ? Pourquoi existe-t'il des trous
dans la numérotation de ma colonne séquentielle
(SERIAL) ?

4.16) Qu'est-ce qu'un OID?
Qu'est-ce qu'un TID ?
4.17) A quoi correspond certains termes
utilisés avec PostgreSQL ?
4.18) Pourquoi ai-je l'erreur ERROR: Memory
exhausted in AllocSetAlloc() ?

4.19) Comment puis-je connaître la
version de PostgreSQL que j'utilise ?
4.20) Pourquoi ai-je invalid large obj
descriptor lors d'opérations avec des gros
objets ?
4.21) Comment puis-je créer une colonne
qui aura par défaut l'heure actuelle comme
valeur ?

4.22) Pourquoi mes sous-requêtes
utilisant IN sont-elles si
lentes ?
4.23) Comment puis-je réaliser une
jointure externe ?
4.24) Comment puis-je lancer des requêtes
utilisant plusieurs bases de données ??

4.25) Comment puis-je renvoyer plusieurs lignes
ou colonnes à partir d'une fonction ?
4.26) Why can't I reliably create/drop
temporary tables in PL/PgSQL functions?
4.27) Quelles options de replication sont
disponibles ?
4.28) Quelles options de cryptage sont
disponibles ?

Etendre PostgreSQL

5.1) J'ai écrit une fonction utilisateur.
Lorsque je l'exécute avec psql, pourquoi cela
finit-il avec un "dump core" ?
5.2) Comment puis-je contribuer avec de nouveaux
types et fonctions pour PostgreSQL ?
5.3) Comment puis-je écrire une fonction
C pour récupérer une ligne ?

5.4) J'ai modifié un fichier source.
Pourquoi la modification n'est-elle pas visible après la
recompilation ?

---

Questions générales

1.1) Qu'est ce que PostgreSQL ? Comment
le prononcer ?

PostgreSQL se prononce Post-Gres-Q-L. Un fichier audio
est disponible sur http://www.postgresql.org/postgresql.mp3
pour ceux souhaitant entendre la prononciation.

PostgreSQL est une amélioration du système de
gestion de bases de données POSTGRES (et est toujours
quelque fois appelé "Postgres"), un prototype de recherche
de SGBD de prochaine génération.
PostgreSQL garde le puissant modèle de données et les
types de données riches de POSTGRES, mais remplace le
langage de requêtes PostQuel par un sous-ensemble

étendu de SQL. PostgreSQL est gratuit et les
sources complets sont disponibles.

PostgreSQL est écrit par une équipe de
développeurs qui sont tous inscrits à la liste de
diffusion de développement de PostgreSQL. Le coordinateur
actuel est Marc G. Fournier (scrappy@PostgreSQL.org et voir
la section 1.6 pour contacter les
développeurs). Cette équipe est responsable de tout
le développement de PostgreSQL. C'est un projet soutenu par
une communauté sans être contrôlé par une
société. Pour y contribuer, voir la FAQ des
développeurs sur http://www.postgresql.org/docs/faqs/FAQ_DEV.html.

Les auteurs de PostgreSQL 1.01 étaient Andrew Yu et Jolly
Chen. Beaucoup d'autres personnes ont contribué au portage,
aux tests, au déboguage et à l'amélioration du
code. Le code de Postgres original, duquel PostgreSQL est
dérivé, était le fruit de l'effort de nombreux
étudiants diplômés et non
diplômés, et de programmeurs travaillant sous la
direction du Professeur Michael Stonebraker à

l'université de Californie, Berkeley.

Le nom original du logiciel à Berkeley était
Postgres. Quand le SQL fut ajouté en 1995, le
nom a dû être changé en Postgres95. Fin 1996, le
nom fut changé en PostgreSQL.

1.2) Quelle est la licence de
PostgreSQL ?

PostgreSQL est distribué sous la licence
suivante :

PostgreSQL Data Base Management System

Portions copyright (c) 1996-2004, PostgreSQL Global Development
Group Portions Copyright (c) 1994-6 Regents of the University of
California

Permission to use, copy, modify, and distribute this software
and its documentation for any purpose, without fee, and without a
written agreement is hereby granted, provided that the above
copyright notice and this paragraph and the following two
paragraphs appear in all copies.

IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY
PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS
SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF
CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE
SOFTWARE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE
UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE,
SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

La licence ci-dessus est la licence BSD, une licence open-source
classique.

1.3) Sous quels environnements Unix
PostgreSQL tourne-t-il ?

En général, tout environnement compatible Unix
moderne devrait pouvoir faire fonctionner PostgreSQL. Les
environnements qui ont été testés
explicitement sont listés dans les instructions
d'installation.

1.4) Sous quels environnements non Unix
PostgreSQL fonctionne-t'il ?

Client

Il est possible de compiler la bibliothèque C
libpq, psql et d'autres interfaces et applications clientes
pour qu'elles tournent sous des environnements MS Windows. Dans ce
cas, le client tourne sous MS Windows et communique par TCP/IP avec
un serveur tournant sous un environnement Unix supporté. Un
fichier win32.mak est inclus dans la distribution pour
construire une bibliothèque libpq psql Win32.
PostgreSQL communique aussi avec des clients

ODBC.

Serveur

Le serveur de base de données peut tourner sous Windows
NT et Windows 2000 en utilisant Cygwin, la bibliothèque de
portage Unix/NT de Cygnus. Voir pgsql/doc/FAQ_MSWIN dans la
distribution ou la FAQ MS Windows sur http://www.PostgreSQL.org/docs/faqs/text/FAQ_MSWIN.

Un port natif sur MS Windows NT/2000/XP est en court. Pour plus
de détails sur le statut actuel de PostgreSQL sur Windows,
voir http://techdocs.postgresql.org/guides/Windows

et http://momjian.postgresql.org/main/writings/pgsql/win32.html.

Il existe aussi un port sur Novell Netware sur http://forge.novell.com.

1.5) Où puis-je me procurer
PostgreSQL ?

Le site FTP anonyme principal de PostgreSQL est ftp://ftp.PostgreSQL.org/pub.
Pour les sites miroirs, voir notre site web principal.

1.6) Où puis-je obtenir du
support ?

La liste de diffusion principale est pgsql-general@PostgreSQL.org.
Elle est disponible pour discuter de sujets en rapport avec
PostgreSQL. Pour s'y inscrire, il faut envoyer un courriel avec les
lignes suivantes dans le corps du message (pas dans la ligne du
sujet) :

    subscribe

    end

à pgsql-general-request@PostgreSQL.org.

Il existe aussi un recueil de la liste. Pour s'y inscrire,
envoyez un courriel à pgsql-general-digest-request@PostgreSQL.org
avec dans le corps :

    subscribe

    end

Les recueils sont envoyés aux membres de cette liste
dès que la liste principale a reçu 30 Ko de messages.

Une liste de diffusion de bogues est disponible. Pour s'y
inscrire, envoyer un courriel à pgsql-bugs-request@PostgreSQL.org

avec dans le corps :

    subscribe

    end

Une liste de diffusion pour les développeurs est aussi
disponible. Pour s'y inscrire, envoyez un courriel à
pgsql-hackers-request@PostgreSQL.org
avec dans le corps :

    subscribe

    end

Vous pouvez trouver d'autres listes et informations sur
PostgreSQL sur le site web de PostgreSQL :

http://www.PostgreSQL.org

Il y a aussi un canal IRC sur Freenode et EFNet, le canal
#PostgreSQL. Vous pouvez utiliser la commande Unix irc
-c '#PostgreSQL' "$USER" irc.phoenix.net ou irc -c
'#PostgreSQL' "$USER" irc.freenode.net.

Une liste de sociétés pouvant fournir un support
commercial est disponible sur http://techdocs.postgresql.org/companies.php.

1.7) Quelle est la dernière version
?

La dernière version de PostgreSQL est la version
7.4.3.

Nous projetons de sortir une version majeure tous les six
à huit mois.

1.8) Quelle documentation est disponible
?

Plusieurs manuels, pages de manuel ainsi que des petits exemples
de test sont inclus dans la distribution. Voir le répertoire
/doc. Vous pouvez aussi accéder aux manuels en ligne
sur http://www.PostgreSQL.org/docs.

Deux livres sur PostgreSQL sont disponibles en ligne sur
http://www.PostgreSQL.org/docs/awbook.html
et http://www.commandprompt.com/ppbook/.
Il y a une liste de livres sur PostgreSQL pouvant être
achetés sur http://techdocs.PostgreSQL.org/techdocs/bookreviews.php.
Il y a aussi une collection d'articles techniques sur PostgreSQL
sur http://techdocs.PostgreSQL.org/.

psql possède des commandes \d pratiques montrant
des informations sur les types, opérateurs, fonctions,
aggrégats, etc.

Notre site web contient encore plus de documentations.

1.9) Comment savoir quels sont les bogues
connus ou les fonctionnalités manquantes ?

PostgreSQL supporte un sous-ensemble étendu de
SQL-92. Voir notre liste TODO pour les bogues
connus, les fonctionnalités manquantes et les plans pour le
futur.

1.10) Comment puis-je apprendre le

SQL ?

Le livre PostgreSQL sur http://www.PostgreSQL.org/docs/awbook.html
enseigne le SQL. Il existe un autre livre PostgreSQL
sur http://www.commandprompt.com/ppbook.
Il existe de bons tutoriels sur http://www.intermedia.net/support/sql/sqltut.shtm,

http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM

et http://sqlcourse.com.

Un autre (en anglais uniquement) "Teach Yourself SQL in 21 Days,
Second Edition" se trouve sur http://members.tripod.com/er4ebus/sql/index.htm

Nombre de nos utilisateurs aiment The Practical SQL
Handbook, Bowman, Judith S., et al., Addison-Wesley. D'autres
aiment The Complete Reference SQL, Groff et al.,
McGraw-Hill.

1.11) PostgreSQL est-il compatible an 2000
?

Oui, nous manipulons facilement les dates après et avant
l'an 2000.

1.12) Comment puis-je rejoindre
l'équipe de développement ?

Tout d'abord, téléchargez les derniers sources et
lisez la documentation pour les développeurs sur notre site
web ou bien dans la distribution. Ensuite, inscrivez-vous aux
listes de diffusion pgsql-hackers et pgsql-patches.
Et pour finir, soumettez des correctifs de grande qualité
sur pgsql-patches.

Environ une douzaine de personnes ont des droits de modification
sur l'archive CVS de PostgreSQL. Ils ont chacun
soumis tellement de correctifs de qualité qu'il était
devenu impossible aux développeurs de tenir la cadence et
nous avions confiance dans le qualité des correctifs qu'ils
soumettaient.

1.13) Comment dois-je soumettre un rapport
de bogue ?

Merci de visiter la page PostgreSQL BugTool sur http://www.PostgreSQL.org/bugs/bugs.php,
qui donne des indications sur la façon de soumettre un
rapport de bogue.

De même, vérifiez notre site ftp ftp://ftp.PostgreSQL.org/pub
pour voir s'il existe une version PostgreSQL plus récente ou
des correctifs.

1.14) Comment PostgreSQL se compare-til
à d'autres SGBD ?

Il y a plusieurs manières de mesurer un logiciel : les
fonctionnalités, les performances, la fiabilité, le
support, et le prix.

Fonctionnalités

PostgreSQL possède la plupart des fonctionnalités
présentes dans les SGBD commerciaux, comme
les transactions, les requêtes imbriquées, les
déclencheurs, les vues, l'intégrité
référentielle par clés

étrangères, et le verrouillage sophistiqué.
Nous avons des fonctionnalités qu'ils n'ont pas, comme les
types définis par l'utilisateur, l'héritage, les
règles, et le contrôle de concurrence par
multi-versionnage pour réduire les contentions de
verrouillage.

Performances

PostgreSQL a des performances similaires aux autres bases de
données commerciales et open source. Il est plus rapide pour
certaines opérations, plus lent pour d'autres. Par rapport
à MySQL ou d'autres SGBD plus léger,
nous sommes plus rapides pour de nombreux utilisateurs, des
requêtes complexes et une charge pour les requêtes de
lecture/écriture. MySQL est plus rapide pour des
requêtes SELECT simples effectuées par quelques
utilisateurs. Bien sûr, MySQL ne possède aucune des
fonctionnalités de la section Fonctionnalités

ci-dessus. PostgreSQL est construit pour la fiabilité et les
fonctionnalités et nous continuons à améliorer
les performances à chaque version. Il y a une page web
intéressante qui compare PostgreSQL à MySQL sur
http://openacs.org/philosophy/why-not-mysql.html.
De plus, MySQL est une société qui distribue son
produit via l'open source et requiert une licence commerciale pour
les logiciels propriétaires, donc pas une communauté

de développement open source comme PostgreSQL.

Fiabilité

Nous somme conscients qu'un SGBD doit être
fiable ou bien il est inutile. Nous faisons le maximum pour sortir
des versions bien testées, du code stable ne contenant qu'un
minimum de bogues. Chaque version a au moins un mois de tests, et
notre historique de versions montre que nous pouvons fournir des
versions stables et robustes, prêtes pour une utilisation en
environnement de production. Nous pensons que nous nous comparons
favorablement aux autres bases de données dans ce
domaine.

Support

Nos listes de diffusion offrent un contact avec un large groupe
de développeurs et d'utilisateurs afin d'aider à la
résolution des problèmes rencontrés. Nous ne
pouvons garantir un correctif mais les SGBD
commerciaux ne le garantissent pas toujours non plus.
L'accès direct aux développeurs, à la
communauté d'utilisateurs, aux manuels, et au code source,
fait du support pour PostgreSQL un support supérieur aux
autres SGBD. Un support commercial par incident est
disponible pour ceux qui en ont le besoin (voir la section 1.6 de la FAQ).

Prix

Nous sommes gratuits pour tous les usages, commerciaux et non
commerciaux. Vous pouvez inclure notre code dans vos produits sans
limitation, exceptées celles citées dans notre
licence de type BSD donnée plus haut.

1.15) Comment puis-je aider
financièrement PostgreSQL ?

PostgreSQL possède une infrastructure de première
classe depuis le début en 1996. Ceci grâce à

Marc Fournier, qui a créé et géré cette
infrastructure des années durant.

Une infrastructure de qualité est importante pour un
projet open-source. Cela permet d'empêcher
l'éparpillement qui ralentirait beaucoup l'avancement du
projet.

Bien sûr, cette infrastructure n'est pas donnée.
Elle requiert un certain nombre de dépenses mensuelles ou
ponctuelles. Si vous ou votre société peut donner de
l'argent pour soutenir cet effort, merci de consulter la page web

http://store.pgsql.com/shopping/
et de faire une donation.

Bien que la page web mentionne PostgreSQL, Inc, les
contributions sont exclusivement utilisées pour soutenir le
projet PostgreSQL et ne soutiennent aucune société
que ce soit. Si vous le préférez, vous pouvez aussi
envoyer un chèque à l'adresse de contact.

---

De plus, si vous avez une histoire de succès avec
PostgreSQL, merci de la soumettre à notre site
d'évangélisation sur http://advocacy.postgresql.org.

Questions sur le client utilisateur

2.1) Existe-t'il des pilotes
ODBC pour PostgreSQL ?

Il y a deux pilotes ODBC disponibles, PsqlODBC et
OpenLink ODBC.

Vous pouvez télécharger PsqlOBDC depuis http://gborg.postgresql.org/project/psqlodbc/projdisplay.php.

OpenLink ODBC peut être obtenu depuis
http://www.openlinksw.com.
Il fonctionne avec leur logiciel client ODBC
standard, vous aurez donc PostgreSQL ODBC sur toutes
les plateformes client qu'ils supportent (Win, Mac, Unix, VMS).

Ils vendront probablement ce produit aux gens qui recherchent
une qualité de support professionnelle mais une version
freeware sera toujours disponible. Merci d'envoyer vos questions

à postgres95@openlink.co.uk.

2.2) Quels outils sont disponibles pour
utiliser PostgreSQL avec des pages Web ?

Une bonne introduction aux pages Web adossés à une
base de données se trouve à http://www.webreview.com

Pour l'intégration Web, PHP est une excellente interface.
Elle se trouve à http://www.php.net.

Pour les cas complexes, beaucoup utilisent l'interface Perl et
CGI.pm ou mod_perl.

2.3) PostgreSQL a-t-il une interface
graphique ?

Oui, il y a plusieurs interfaces graphiques disponibles pour
PostgreSQL, dont PgAccess http://www.pgaccess.org), PgAdmin III
(http://www.pgadmin.org), RHDB
Admin (http://sources.redhat.com/rhdb/
et Rekall ( http://www.thekompany.com/products/rekall/,
propriétaire). Il y a aussi PhpPgAdmin ( http://phppgadmin.sourceforge.net/

), une interface Web pour PostgreSQL.

Voir http://techdocs.postgresql.org/guides/GUITools
pour une liste plus détaillée.

2.4) Quels langages sont disponibles pour
communiquer avec PostgreSQL ?

La plupart des langages de programmation couramment
utilisés ont une interface pour PostgreSQL. Vérifiez
la liste des modules de votre langage.

Les interfaces ci-dessous sont incluses dans la distribution
:

• C (libpq)
• Embedded C (ecpg)
• Java (jdbc)
• Python (PyGreSQL)
• TCL (libpgtcl)

Interfaces supplémentaires disponibles sur http://gborg.postgresql.org dans
la section Drivers/Interfaces

---

Questions Administratives

3.1) Comment installer PostgreSQL ailleurs
que sous /usr/local/pgsql ?

Il faut spécifier l'option --prefix lors du
lancement de configure.

3.2) Quand je lance postmaster,
j'obtiens un Bad System Call ou un message core
dumped . Pourquoi ?

Cela peut être dû à une variété

de problèmes mais vérifiez d'abord que vous avez les
extensions System V installées pour votre noyau. PostgreSQL
nécessite le support noyau pour la mémoire
partagée et les sémaphores.

3.3) Quand je lance postmaster,
j'obtiens des erreurs IpcMemoryCreate. Pourquoi ?

Soit vous n'avez pas configuré correctement la
mémoire partagée dans votre noyau, soit vous devez
augmenter la mémoire partagée disponible dans le
noyau. Le montant exact dont vous avez besoin dépend de
votre architecture et du nombre de tampons et de processus que vous
avez configuré pour postmaster. Pour la plupart des
systèmes avec un nombre par défaut de tampons et de
processus, vous aurez besoin d'un minimum d'environ 1 Mo. Voir le
chapitre

Administration du manuel PostgreSQL pour des informations plus
détaillées sur la mémoire partagée et
les sémaphores.

3.4) Quand je lance postmaster,
j'obtiens des erreurs IpcSemaphoreCreate. Pourquoi ?

Si le message d'erreur est IpcSemaphoreCreate: semget failed
(No space left on device) alors votre noyau n'est pas
configuré avec suffisamment de sémaphores. PostgreSQL
a besoin d'un sémaphore par processus serveur potentiel. Une
solution provisoire est de lancer postmaster avec une plus
petite limite sur le nombre de processus serveur. Utilisez l'option

-N avec un paramètre inférieur au choix par
défaut de 32. Une solution permanente est d'augmenter les
paramètres SEMMNS et SEMMNI de
votre noyau.

Des sémaphores inopérantes peuvent aussi provoquer
des plantages pendant de gros accès à la base de
données.

Si le message d'erreur est autre chose, vous n'avez
peut-être pas du tout le support des sémaphores dans
votre noyau. Voir le chapitre
Administration du manuel PostgreSQL pour des informations plus
détaillées sur la mémoire partagée et
les sémaphores.

3.5) Comment contrôler les connexions
d'autres machines ?

Par défaut, PostgreSQL n'autorise que les connexions de
la machine locale utilisant les sockets de domaine Unix. D'autres
machines ne seront pas capables de se connecter sauf si vous
configurez tcpip_sockets dans postgresql.conf et
activez l'authentification basée sur l'hôte en
modifiant le fichier $PGDATA/pg_hba.conf en
conséquence. Ceci autorisera les connexions TCP/IP.

3.6) Comment régler le moteur de la
base de données pour de meilleures performances ?

Des index accéléreront les requêtes. La
commande EXPLAIN ANALYZE vous permet de voir comment
PostgreSQL traite votre requête et quels index sont
utilisés.

Si vous faites beaucoup d'insertions (instruction
INSERT), envisagez de les faire en une fois en
utilisant la commande COPY. Ceci est plus rapide que
des commandes INSERTS individuelles.
Deuxièment, les requêtes qui ne sont pas dans des
blocs de transaction BEGIN WORK/COMMIT sont
considérés comme étant dans leur propre
transaction. Envisagez de faire plusieurs instructions dans un seul
bloc de transaction. Ceci réduira la surcharge
apportée par les transactions. Aussi, envisagez d'abandonner
et de recréer des index lors de grosses modifications de
données.

Il y a plusieurs options d'optimisations. Vous pouvez
désactiver fsync() en lançant
postmaster avec l'option -o -F. Ceci empêchera
les fsync()s d'écrire sur disque après toute
transaction.

Vous pouvez utiliser l'option -B de postmaster
pour augmenter le nombre de tampons de mémoire
partagée utilisés par les processus serveurs. Si vous
fixez ce paramètre trop haut, postmaster ne se
lancera pas car vous avez dépassé la limite de votre
noyau sur la quantité de mémoire partagée.
Chaque tampon fait 8 Ko et le choix par défaut est de 64
tampons.

Vous pouvez utiliser l'option serveur -S pour augmenter
la quantité maximale de mémoire utilisée par
les processus serveurs pour des tris temporaires. La valeur de
-S est mesuré en kilooctets et le choix par
défaut est de 512 (c'est-à-dire 512 Ko).

Vous pouvez utiliser la commande CLUSTER pour
regrouper vos données en tables pour correspondre à

un index. Voir la page de manual CLUSTER pour plus
de détails.

3.7) Quelles fonctionalités de
déboguage sont disponibles ?

PostgreSQL a plusieurs fonctionalités qui permettent de
recueillir des informations de statut qui peuvent être utile
pour des intentions de déboguage.

D'abord, en lançant configure avec l'option
--enable-cassert, beaucoup d'assert()s surveillent le
serveur et arrêtent le programme quand quelque chose
d'inattendu arrive.

Postmaster et postgres ont tous deux plusieurs
options de déboguage de disponible. D'abord, quand vous
lancez postmaster, vérifiez que vous envoyez les
sorties standard et d'erreur dans un fichier de traces comme :

    cd /usr/local/pgsql

    ./bin/postmaster >server.log 2>&1 &

Ceci va créer un fichier server.log dans le
répertoire racine de PostgreSQL. Ce fichier contient des
informations utiles sur les problèmes ou erreurs
rencontrés par le serveur. Postmaster dispose d'une
option -d qui permet de rapporter des informations encore
plus détaillées d'être rapportées.
L'option -d prend un numéro qui spécifie le
niveau de déboguage. Faites attention au fait que des
valeurs élévées de niveau de déboguage
génerent des fichiers de traces volumineux.

Si postmaster ne tourne pas, vous pouvez lancer le
serveur postgres de la ligne de commande et taper votre
requête SQL directement. Ceci est
recommandé seulement pour des fonctions de
déboguage. Notez qu'un retour chariot termine la
requête, pas un point-virgule. Si vous compilez avec les
symboles de déboguage, vous pouvez utiliser un
débogueur pour voir ce qui se passe. Parce que le serveur
n'a pas été lancé par postmaster, il ne
tourne pas dans un environnement identique et les problèmes
d'interaction de verrouillage/serveur ne peuvent être
dupliqués.

Si postmaster est en train de tourner, lancez psql
dans une fenêtre puis trouvez le PID du
processus postgres utilisé par psql. Utilisez
un débogueur pour l'attacher au PID

postgres. Vous pouvez mettre un point d'arrêt dans le
débogueur et envoyez des requêtes de psql. Si
vous déboguez le démarrage de postgres, vous
pouvez mettre PGOPTIONS="-W n", puis lancez psql. Ceci va
retarder le démarrage de n secondes pour que vous
puissiez attacher un débogueur au processus, fixer des
points d'arrêt et continuer la séquence de
démarrage.

Le programme postgres a les options -s, -A et
-t qui peuvent être utile pour des mesures de
déboguage et de performance.

Vous pouvez compiler avec les options de performance pour voir
quelles fonctions prennent du temps d'exécution. Les
fichiers de gestion du serveur seront déposés dans le
répertoire pgsql/data/base/nom_db. Les fichiers de
gestion clients seront mis dans le répertoire actuel du
client. Linux requiert une compilation avec -DLINUX_PROFILE

pour une meilleure gestion.

3.8) Pourquoi est-ce que j'obtiens des
messages Sorry, too many clients quand je me connecte ?

Vous pouvez augmenter la limite de postmaster sur le
nombre de processus serveur concurrents qu'il peut lancer.

La limite par défaut est de 32 processus. Vous pouvez
l'augmenter en relançant postmaster avec une valeur

-N appropriée ou en modifiant
postgresql.conf.

Tenez compte du fait que si vous fixez -N plus grand que
32, vous devez aussi augmenter -B au-dela de sa valeur par
défaut 64 ; -B doit valoir au moins deux fois

-N et probablement plus pour une meilleure performance. Pour
de grand nombres de processus serveurs vous aurez probablement
aussi augmenter plusieurs parametres de configuration du noyau
Unix. Les choses a vérifier incluent la taille maximale des
blocs de mémoire partagée, SHMMAX ; le
nombre maximal de sémaphores, SEMMNS et
SEMMNI ; le nombre maximal de processus,
NPROC ; le nombre maximal de processus par
utilisateur, MAXUPRC ; et le nombre maximal de
fichiers ouverts, NFILE et NINODE. La
raison pour laquelle PostgreSQL a une limite sur le nombre de
processus serveurs autorisés est pour que votre
système ne tombe pas à court de ressources.

3.9) Que contient le répertoire
pgsql_tmp ?

Ce répertoire contient des fichiers temporaires
générés par le moteur de requête. Par
exemple, si un tri doit être fait pour satisfaire un
ORDER BY et que ce tri requiert plus de place que le
paramètre -S du serveur n'autorise, alors des
fichiers temporaires seront créés pour contenir les
données nécessaires.

Les fichiers temporaires sont d'habitude effacés
automatiquement mais peuvent rester si un serveur s'arrête
brutalement pendant un tri. Un arrêt et un redémarrage
de postmaster effacera les fichiers dans ces
répertoires.

3.10) Pourquoi est-ce que j'ai besoin de
faire une sauvegarde des bases et de restaurer pour mettre a jour
les versions de PostgreSQL ?

L'équipe PostgreSQL ne fait que des changements mineurs
entre des versions mineurs, donc mettre à jour de 7.2 vers
7.2.1 ne nécessitera pas de sauvegarde et de restauration.
Par contre, les sorties majeures (c'est-à-dire de 7.2 vers
7.3) changent souvent le format interne des tables systèmes
et des fichiers de données. Ces modifications sont souvent
complexes alors nous ne gardons pas de compatibilité

descendante pour les fichiers de données. Une sauvegarde
exportera les données dans un format générique
qui peut ensuite être chargé dans le nouveau format
interne.

Dans les sorties où le format sur disque ne change pas,
le script pg_upgrade peut être utilisé pour
mettre à jour sans sauvegarde/restauration. Les notes de
sorties précisent si pg_upgrade est disponible pour
la sortie.

3.11) Quels matériels dois-je
utiliser ?

Comme le matériel PC est compatible en grosse partie, les
gens ont tendance à croire que tous les matériels PC
sont de même qualité. Ce n'est pas le cas. La RAM ECC,
le SCSI et les cartes-mère de qualité sont plus
fiables et ont de meilleurs performances qu'un matériel
moins coûteux. PostgreSQL fonctionnera sur à peu
près tout matériel mais si la fiabilité et la
performance sont importantes pour vous, il est rusé de bien
considérer les options matérielles. Nos listes de
diffusion peuvent être utilisées pour discuter des
options matériels.

---

Questions fonctionnelles

4.1) Quelle est la différence entre
curseur binaire et curseur normal ?

Voir la page DECLARE du manuel pour une
description.

4.2) Comment faire un SELECT
seulement sur les premières lignes d'une requête ? Sur
une ligne aléatoire ?

Voir la page FETCH du manuel ou utiliser
SELECT ... LIMIT....

Il se peut que l'intégralité de la requête
doive être évaluée, même si vous voulez
seulement les premières lignes. Envisagez d'utiliser une
requête avec une clause ORDER BY. S'il existe
un index correspondant à l'ORDER BY,
PostgreSQL peut n'évaluer que les premières lignes,
sinon l'intégralité de la requête peut

être évaluée, jusqu'à
générer les lignes désirées.

Pour faire un SELECT sur une ligne
aléatoire :

    SELECT colonne

    FROM table

    ORDER BY random()

    LIMIT 1;

4.3) Comment obtenir une liste des tables ou
d'autres objets que je vois dans psql ?

Utilisez la commande \dt pour voir les tables dans psql.
Pour une liste complète de commandes à
l'intérieur de psql, vous pouvez utiliser \?. Autrement,
vous pouvez lire le code source de psql dans le fichier

pgsql/src/bin/psql/describe.c. Il contient des commandes
SQL qui génèrent le contenu des
commandes anti-slash de psql. Vous pouvez aussi lancer psql
avec l'option -E, afin qu'il imprime les requêtes
qu'il utilise pour exécuter les commandes que vous lui
passez. PostgreSQL fournit aussi une interface d'informations sur
le schéma compatible avec SQLi que vous pouvez
interroger des informations sur la base de données.

4.4) Comment supprime-t-on une colonne d'une
table, ou comment change-t-on son type de données ?

La fonction DROP COLUMN a été
ajoutée dans la version 7.3 avec ALTER TABLE DROP
COLUMN. Pour les versions précédentes, vous
pouvez faire :

    BEGIN;

    LOCK TABLE ancienne_table;

    SELECT ...  -- sélectionnez toutes les colonnes sauf celle à supprimer

    INTO TABLE nouvelle_table

    FROM ancienne_table;

    DROP TABLE ancienne_table;

    ALTER TABLE nouvelle_table RENAME TO ancienne_table;

    COMMIT;

Pour changer le type de données d'une colonne, faites
:

    BEGIN;

    ALTER TABLE table ADD COLUMN nouvelle_colonne nouveau_type_de_donnees;

    UPDATE table SET nouvelle_colonne = CAST(ancienne_colonne AS nouveau_type_de_donnees);

    ALTER TABLE table DROP COLUMN ancienne_colonne;

    COMMIT;

Après, vous pouvez faire VACUUM FULL tab pour
récupérer l'espace disque utilisé par les
lignes expirées.

4.5) Quelle est la taille maximale pour une
ligne, une table, une base de données ?

Les limites sont :

    Taille maximum pour une base de données     illimitée (il existe des bases de 32 To)

    Taille maximum pour une table               32 To

    Taille maximum pour une ligne               1,6 To

    Taille maximum pour un champ                1 Go

    Nombre maximum de lignes dans une table     illimité

    Nombre maximum de colonnes dans une table   250-1600, selon le type de colonnes

    Nombre maximum d'index sur une table        illimité

Bien sûr, ces valeurs ne sont pas vraiment
illimitée, elles sont limitées par l'espace disque
disponible, ainsi que par l'espace de mémoire et de swap.
Les performances peuvent se dégrader si ces valeurs sont
inhabituellement grandes.

La taille maximum des tables (32 To) ne nécessite pas que
le système d'exploitation supporte les grands fichiers. Les
grandes tables sont stockées sous forme de fichiers
multiples de 1 Go, donc les limites de taille du système de
fichier ne sont pas importantes.

La taille maximum des tables et le nombre maximum de colonnes
peuvent être quadriplés, si la taille des blocs par
défaut est augmentée à 32 Ko.

4.6) Combien d'espace disque faut-il pour
stocker les données d'un fichier texte typique ?

Une base de données PostgreSQL peut utiliser
jusqu'à cinq fois l'espace nécessaire pour stocker
les données d'un fichier texte.

A titre d'exemple, considérez un fichier de 100 000
lignes, comportant un entier et une chaîne de description sur
chaque ligne. Supposons que la chaîne soit longue en moyenne
de 20 octets. Le fichier texte serait de 2,8 Mo. La taille du
fichier d'une base de données PostgreSQL peut être
estimée à 6,4 Mo :

    36 octets: chaque ligne (approximation)

    24 octets: un champ 'entier' et un champ 'texte'

   + 4 octets: pointeur vers le tuple sur la page

   ----------------------------------------

    64 octets par ligne

   La taille des pages de données dans PostgreSQL est de 8192 octets (8 KO), donc :
   8192 octets par page

   ----------------------   = 128 lignes par page de base de données (arrondi à l'entier inférieur)

     64 octets par ligne
   100000 lignes de données

   -------------------------  =  782 pages de base de données (arrondi à l'entier supérieur)

      128 lignes par page
782 pages de base de données * 8192 octets par page  =  6 406 144 octets (6,4 Mo)

Les index utilisent moins d'espace, mais ils contiennent les
données indexées, ils peuvent donc également

être grands.

Les NULL sont stockés sous forme de
bitmap, aussi utilisent-ils très peu d'espace.

4.7) Comment puis-je savoir quels index,
tables, bases de données et utilisateurs sont définis
?

psql dispose de plusieurs commandes commençant par
un anti-slash pour retrouver ces informations. Utilisez \? pour les
connaître. Il existe aussi des tables systèmes, qui
commencent par pg_ et qui les décrivent

également. Aussi, psql -l liste toutes les bases de
données.

Essayez également le fichier
pgsql/src/tutorial/syscat.source. Il illustre un grand
nombre de commandes SELECT nécessaires pour
récupérer l'information des tables système de
la base de données.

4.8) Mes requêtes sont lentes ou ne
font pas usage des index. Pourquoi ?

Les index ne sont pas automatiquement utilisés par chaque
requête. Ils sont utilisés uniquement si la table est
plus grande qu'une certaine taille, et si la requête
sélectionne seulement un faible pourcentage des lignes de la
table. Ceci est dû au fait qu'un accès disque
aléatoire causé par un parcours d'index peut
être plus lent qu'une simple lecture de la table, ou parcours
séquentiel

Pour déterminer si un index devrait être
utilisé, PostgreSQL a besoin des statistiques de la table.
Ces statistiques sont collectées en lançant
VACUUM ANALYZE ou simplement ANALYZE.
Avec les statistiques, l'optimiseur sait combien de lignes se
trouvent dans la table et peut mieux déterminer s'il faut
utiliser l'index. Les statistiques sont également utiles
pour déterminer l'ordre optimal des opérations de
jointure. La collecte des statistiques devrait être
effectuée régulièrement lorsque le contenu de
la table change.

Les index ne sont normalement pas utilisés pour les
clauses ORDER BY ou pour les jointures. Un parcours
séquentiel suivi d'un tri explicite est habituellement plus
rapide qu'un parcours d'index pour une table importante. Toutefois,
LIMIT combiné avec ORDER BY
utilisera souvent un index parce que seulement une petite partie de
la table est renvoyée. En fait, bien que MAX() et MIN()
n'utilisent pas les index, il est possible de retrouver ces valeurs
en utilisant un index avec ORDER BY et LIMIT :

    SELECT colonne

    FROM table

    ORDER BY colonne [ DESC ]

    LIMIT 1;

Si vous pensez que l'optimiseur choisit par erreur un parcours
sequentiel, utilisez SET enable_seqscan TO 'off' et
lancez des tests pour voir si le parcours d'index est effectivement
plus rapide.

Lorsque vous utilisez des caractères joker tels que
LIKE ou ~, les index peuvent seulement
être utilisés dans certaines circonstances :

• Le début de la chaîne de recherche doit être
  ancré au départ de la chaîne,
  c'est-à-dire
  • Les modèles pour LIKE ne doivent pas
    commencer par %.
  • Les modèles d'expression régulière pour
    ~ doivent commencer par ^.
• La chaîne de recherche ne peut pas commencer par une
  classe de caractères, c'est-à-dire [a-e].
• Les recherches sans casse comme ILIKE et
  ~* n'utilisent pas les index. Utilisez plutôt les
  index fonctionnels, décrit dans la section 4.12.
• La locale C par défaut doit être
  utilisée lors de initdb.

4.9) Comment puis-je savoir si l'optimiseur
évalue mes requêtes ?

Voir la page EXPLAIN du manuel.

4.10) Qu'est-ce qu'un index R-tree ?

Un index R-tree est utilisé pour l'indexation des
données spatiales. Un index de hachage ne permet pas les
recherches par plage. Un index B-tree peut seulement faire des
recherches sur une dimension. Les index R-tree peuvent traiter des
données multi-dimensionnelles. Par exemple, si un index
R-tree peut être construit sur un attribut de type

point, le système peut plus efficacement gérer
les requêtes du type "Sélection de tous les points
d'un rectangle".

L'article de référence qui décrit le
système R-tree original est :

Guttman, A. "R-trees: A Dynamic Index Structure for Spatial
Searching." Proceedings of the 1984 ACM SIGMOD Int'l Conf on Mgmt
of Data, 45-57.

Vous pouvez également trouver ce papier dans le livre de
Stonebraker "Readings in Database Systems".

Les index R-tree intégrés peuvent prendre en
charge les polygônes et les boîtes. En théorie,
les R-trees peuvent être étendus à un plus
grand nombre de dimensions. En pratique, l'extension des R-trees
requiert pas mal de travail et nous n'avons pour le moment aucune
documentation sur la façon de procéder.

4.11) Qu'est-ce que l'optimiseur
génétique de requêtes ?

Le module GEQO (acronyme de GEnetic Query
Optimizer) accélère l'optimisation des
requêtes lors de jointures de nombreuses tables par un
algorithme génétique (GA). Il permet la gestion des
grosses requêtes de jointures en utilisant une recherche non
exhaustive.

4.12) Comment puis-je réaliser des
recherches sur des expressions rationnelles ainsi que des
recherches non sensibles à la casse ? Comment puis-je
utiliser un index lors de recherches non sensibles à la
casse ?

L'opérateur ~ réalise des recherches
d'expressions rationnelles et ~* le fait sans tenir compte
de la casse. La variante de LIKE non sensible
à la casse est ILIKE.

Des comparaisons d'égalité non sensibles à
la casse sont habituellement exprimées de cette façon
:

    SELECT *

    FROM table

    WHERE lower(colonne) = 'abc';

Ceci n'utilisera pas un index standard. Néanmoins, si
vous créez un index fonctionnel, celui-ci sera
utilisé :

    CREATE INDEX tableindex ON table (lower(colonne));

4.13) Comment puis-je détecter si un
champ est NULL dans une requête ?

Il vous suffit de tester la colonne avec IS NULL
ou IS NOT NULL.

4.14) Quelle sont les différences
entre les nombreux types de caractères ?

Type            Nom interne     Notes

--------------------------------------------------

VARCHAR(n)      varchar         n spécifie la taille maximum, sans remplissage

CHAR(n)         bpchar          des espaces sont ajoutés pour obtenir la

                                longueur fixe spécifiée

TEXT            text            pas de limite supérieure pour la taille

BYTEA           bytea           tableau d'octets (accepte les octets nuls)

"char"          char            un caractère

Vous verrez le nom interne en examinant les catalogues
système et dans quelques messages d'erreur.

Les quatres premiers types du dessus sont des types "varlena"
(c'est-à-dire que les quatre premiers octets correspondent
à la taille, suivi des données). Donc, l'espace
réellement utilisé est légèrement plus
grand que la taille déclarée. Néanmoins, ces
types de données sont aussi sujet à la compression ou
à un enregistrement en dehors de la table avec

TOAST, donc l'espace occupé sur disque
pourrait aussi être moindre que ce qu'on pourrait
attendre.

VARCHAR(n) est bien mieux pour enregistrer des
chaînes de longueurs variables tout en limitant la taille de
cette chaîne. TEXT est utile pour les
chaînes de longueur illimitée, avec malgré tout
un maximum de 1 Go.

CHAR(n) est intéressant pour stocker des
chaînes de taille identique. CHAR(n)
complète avec des espaces pour arriver à la taille
spécifiée alors que VARCHAR(n)
n'enregistre que les caractères donnés.

BYTEA sert à stocker des données
binaires, particulièrement les données incluant des
octets NULL. Tous les types décrits ici ont
des performances similaires.

4.15.1) Comment puis-je créer un
champ série, c'est-à-dire s'incrémentant
automatiquement ?

PostgreSQL supporte un type de données
SERIAL. Il crée automatiquement une
séquence. Par exemple, ceci :

    CREATE TABLE personne (

        id  SERIAL,

        nom TEXT

    );

est automatiquement traduit en ceci :

    CREATE SEQUENCE personne_id_seq;

    CREATE TABLE personne (

        id  INT4 NOT NULL DEFAULT nextval('personne_id_seq'),

        nom TEXT

    );

Voir la page man de create_sequence pour plus d'informations
sur les séquences. Vous pouvez aussi utiliser le champ

OID de chaque ligne comme valeur unique. Néanmoins,
si vous avez besoin de sauvegarder puis recharger la base de
données, vous devrez utiliser l'option -o ou l'option
COPY WITH OIDS de pg_dump pour conserver les
OIDs.

4.15.2) Comment puis-je obtenir la valeur
d'un SERIAL suite à une insertion ?

Une approche pour récupérer la prochaine valeur
SERIAL à partir de l'objet séquence
est d'utiliser la fonction nextval() avant
l'insertion et de l'insérer ensuite explicitement. En
utilisant la table d'exemple de la section 4.15.1, un exemple dans un pseudo-langage
ressemblerait à ceci :

    nouvelle_id = execute("SELECT nextval('personne_id_seq')");

    execute("INSERT INTO personne (id, nom) VALUES (nouvelle_id, 'Blaise Pascal')");

Vous pourriez ensuite utiliser la nouvelle valeur stockée
dans nouvelle_id avec d'autres requêtes
(c'est-à-dire en tant que clé étrangère
de la table personne). Notez que le nom de la
SEQUENCE automatiquement créée sera

<table>_<colonneserial>_seq,
où table et colonneserial sont les noms
respectifs de votre table et de votre colonne
SERIAL.

Autrement, vous pouvez récupérer la valeur

SERIAL affectée avec la fonction
currval() après qu'elle ait été
insérée par défaut, c'est-à-dire,

    execute("INSERT INTO personne (nom) VALUES ('Blaise Pascal')");

    nouvelle_id = execute("SELECT currval('personne_id_seq')");

Enfin, vous pouvez utiliser l'OID renvoyé par l'instruction
INSERT pour récupérer la valeur par
défaut bien que cela soit l'appoche la moins portable et la
valeur de l'OID se réinitialisera aux environs de quatre
milliards. En Perl, avec DBI et le module DBD:Pg d'Edmund Mergl,
l'ancienne valeur est disponible via

$sth->{pg_oid_status} après un
$sth->execute().

4.15.3) Est-ce que currval() et
nextval() n'amènent pas des problèmes lorsque
plusieurs utilisateurs les lancent en même temps ?

Non. currval() renvoie la valeur actuelle affectée
par votre processus, et non pas par tous les utilisateurs.

4.15.4) Pourquoi mes numéros de
séquences ne sont pas ré-utilisés lors d'une
annulation de transaction ? Pourquoi existe-t'il des trous dans la
numérotation de ma colonne séquentielle (SERIAL)
?

Pour améliorer les accès concurrents, les valeurs
de séquences sont données aux transactions qui en ont
besoin et ne sont pas bloquées jusqu'à la fin de la
transaction. Ceci crée des trous dans le numérotage
pour les transactions annulées.

4.16) Qu'est-ce qu'un OID ?
Qu'est-ce qu'un TID ?

Les OID sont la réponse de PostgreSQL aux
identifiants de lignes uniques. Chaque ligne créée
dans PostgreSQL obtient un OID unique. Tous les

OID générés pendant
initdb sont inférieurs à 16384 (voir
include/access/transam.h). Tous les OID
créés par un utilisateur sont supérieurs ou

égaux à ceci. Par défaut, tous ces
OID sont uniques non seulement dans une table ou une
base mais unique à l'intérieur d'une installation
PostgreSQL entière.

PostgreSQL utilise les OID dans ses tables
système interne pour lier les lignes entre tables. Ces

OID peuvent être utilisés pour
identifier des lignes utilisateurs spécifiques et
utilisés dans des jointures. Il est recommandé que
vous utilisiez le type de colonne OID pour stocker
des valeurs OID. Vous pouvez créer un index
sur le champ OID pour un accès plus
rapide.

Les OID sont attribués pour toute ligne
d'un endroit central qui est utilisé par toutes les bases de
données. Si vous voulez changer l'OID en
quelque chose d'autre ou si vous voulez faire une copie de la table
avec les OID originaux, il n'y a pas de raisons pour
ne pas le faire :

    CREATE TABLE nouvelle_table (macolonne int);

    SELECT oid AS ancienne_oid, macolonne INTO table_temporaire FROM ancienne_table;

    COPY table_temporaire FROM '/tmp/tablepg';

    COPY nouvelle_table WITH OIDS FROM '/tmp/tablepg';

    DROP TABLE table_temporaire;

Les OID sont stockés en tant qu'entiers de
quatre octets et déborderont à quatre milliards.
Personne n'a jamais rapporté un tel cas et nous avons
prévu de retirer la limite avant que cela ne se
produise.

Les TIDs sont utilisés pour identifier des
lignes physiques spécifiques avec des valeurs de bloc et
décalage. Les TID changent après que
les lignes aient été modifiés ou
rechargés. Ils sont utilisés par des entrées
d'index pour pointer vers des lignes physiques.

4.17) A quoi correspond certains termes
utilisés avec PostgreSQL ?

Une partie du code source et de l'ancienne documentation
utilisent des termes dont l'usage est plus commun. Voici quelques
exemples :

• table, relation, classe
• ligne (row), enregistrement (record), tuple
• colonne (column), champ (field), attribut
• récupère, sélectionne (select)
• remplace (replace), met à jour (update)
• ajoute (append), insère (insert)
• OID, valeur séquentielle (serial
  value)
• portal, curseur
• range variable, table name, table alias

Une liste des termes généraux pour le domaine des
bases de données est disponible sur :

http://hea-www.harvard.edu/MST/simul/software/docs/pkgs/pgsql/glossary/glossary.html

4.18) Pourquoi ai-je l'erreur ERROR:
Memory exhausted in AllocSetAlloc() ?

Vous manquez probablement de mémoire virtuelle sur votre
système ou votre noyau a une limite assez basse pour
certaines ressources. Essayez ceci avant de lancer
postmaster :

    ulimit -d 262144

    limit datasize 256m

Suivant votre shell, seul un d'eux pourrait réussir mais
cela configurera d'une façon plus importante la taille du
segment de données de votre processus. Cette commande
s'applique au processus actuel et à tous les processus
lancé par celui-ci. Si vous avez des problèmes avec
le client SQL parce que le processus serveur renvoie
trop de données, essayez ça avant de lancer le
client.

4.19) Comment puis-je connaître la
version de PostgreSQL que j'utilise ?

A partir de psql, tapez SELECT
version();

4.20) Pourquoi ai-je invalid large obj
descriptor lors d'opérations sur des gros objects ?

Vous avez besoin de placer BEGIN WORK et
COMMIT autour de chaque utilisateur de gros objets,
c'est-à-dire pour entourer lo_open ...

lo_close.

Actuellement, PostgreSQL force cette règle en fermant les
gros objets lors de la transaction. Donc, le premier essai
d'opérations sur ces objets, fonctionnant habituellement (au
moins la plupart du temps) aura un invalid large obj
descriptor. Donc le code, auparavant fonctionnel (au moins la
plupart du temps), génèrera maintenant un message
d'erreur si vous n'utilisez pas de transaction.

Si vous utilisez une interface client interface comme
ODBC, vous aurez peut-être besoin de lancer
auto-commit off.

4.21) Comment puis-je créer une
colonne qui aura par défaut l'heure actuelle comme valeur
?

Utilisez CURRENT_TIMESTAMP:

CREATE TABLE test (x int, heuremodif timestamp DEFAULT CURRENT_TIMESTAMP );

4.22) Pourquoi mes sous-requêtes
utilisant IN sont-elles si lentes
?

Dans les versions précédant la 7.4, les
sous-requêtes ont été jointes avec des
jointures externes en parcourant séquentiellement le
résultat de la sous-requête pour chaque ligne de la
requête externe. Si la sous-requête renvoit quelques
lignes et que la requête externe en renvoit plein,

IN sera plus rapide. Pour
accélérer les autres requêtes, remplacez
IN avec EXISTS :

    SELECT *

    FROM table

    WHERE colonne IN (SELECT souscolonne FROM soustable);

to:

    SELECT *

    FROM table

    WHERE EXISTS (SELECT souscolonne FROM soustable WHERE souscolonne = colonne);

Pour que ceci soit rapide, souscolonne doit être
une colonne indexée.

A partir de la version 7.4, IN utilise actuellement
les mêmes techniques sophistiquées de jointures comme
des requêtes normales et est préféré

à l'utilisation de EXISTS.

4.23) Comment puis-je réaliser une
jointure externe ?

PostgreSQL supporte les jointures externes en utilisant la
syntaxe SQL standard. Voici deux exemples :

    SELECT *

    FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col);

or

    SELECT *

    FROM t1 LEFT OUTER JOIN t2 USING (col);

Ces requêtes identiques joignent t1.col à t2.col et
renvoient toute colonne non jointe de t1 (celles sans
correspondance dans t2). Une jointure droite (RIGHT
join) ajoutera les lignes non jointes de t2. Une jointure
complète (FULL join) renverra les lignes
correspondantes ainsi que les lignes non jointes de t1 et t2. Le
mot clé OUTER est optionnelle et
assumé dans le cas de jointure LEFT,

RIGHT et FULL. Les jointures
ordinaires sont appelées des jointures
INNER.

Lors des précédentes versions, les jointures
externes peuvent être simulées en utilisant
UNION et NOT IN. Par exemple, lors
d'une jointure de tab1 et tab2, la requête
suivante réalise une jointure externe, outer, des
deux tables :

    SELECT tab1.col1, tab2.col2

    FROM tab1, tab2

    WHERE tab1.col1 = tab2.col1

    UNION ALL

    SELECT tab1.col1, NULL

    FROM tab1

    WHERE tab1.col1 NOT IN (SELECT tab2.col1 FROM tab2)

    ORDER BY col1

4.24) Comment puis-je lancer des
requêtes utilisant plusieurs bases de données ?

Il n'existe pas de moyens de lancer des requêtes sur une
autre base que la courante. Comme PostgreSQL charge des catalogues
systèmes spécifiques à la base de
données, sa réaction aux requêtes inter-base de
données est incertaine.

contrib/dblink permet les requêtes entre bases de
données en utilisant des fonctions. Bien sûr un client
peut réaliser des connexions simultanées à
plusieurs bases de données et joindre les résultats
du côté client.

4.25) Comment puis-je renvoyer plusieurs
lignes ou colonnes à partir d'une fonction?

A partir de la 7.3, vous pouvez facilement renvoyer plusieurs
lignes ou colonnes à partir d'une fonction, http://techdocs.postgresql.org/guides/SetReturningFunctions.

4.26) Pourquoi ne puis-je pas
créer/supprimer des tables temporaires dans les fonctions
PL/PgSQL de façon stable ?

PL/PgSQL cache le contenu des fonctions et un effet de bord
malheureux est que si une fonction PL/PgSQL accède à
une table temporaire, que cette table est ensuite supprimée
et recréée, et que la fonction est appelée de
nouveau, la fonction échouera car le contenu de la fonction
cachée pointera toujours vers l'ancienne table temporaire.
La solution revient à utiliser EXECUTE pour
l'accès aux tables temporaires avec PL/PgSQL. Ceci obligera
l'analyse de la requête à chaque fois.

4.27) Quelles options de réplication
sont disponibles ?

Il existe plusieurs solutions de réplication
maître/esclave. Elles permettent uniquement au maître
de réaliser des changements sur la base de données
alors que l'esclave peut seulement faire des lectures de base de
données. Le bas de la page http://gborg.PostgreSQL.org/genpage?replication_research
les liste. Une solution de réplication multi-maître
est en cours de développement sur

http://gborg.PostgreSQL.org/project/pgreplication/projdisplay.php.

4.28) Quelles options de cryptage sont
disponibles ?

• contrib/pgcrypto contient de nombreuses fonctions de
  cryptage, à utiliser dans des requêtes
  SQL.
• Pour crypter une transmission entre le client et le serveur, le
  serveur doit avoir positionné l'option ssl à

  true dans postgresql.conf, et un enregistrement
  applicable host ou hostssl doit exister dans
  pg_hba.conf, et le sslmode du client ne doit pas

  être désactivée. Notez qu'il est aussi
  possible d'utiliser un transport crypté d'une
  troisième partie, tel que stunnel ou ssh, plutôt que
  les connexions SSL natives de PostgreSQL.

• Les mots de passe des utilisateurs sont automatiquement
  cryptés depuis la version 7.3. Pour les versions
  précédentes, vous devez activer l'option
  PASSWORD_ENCRYPTION dans postgresql.conf.
• Le serveur peut fonctionner avec un système de fichiers
  cryptés.

---

Etendre PostgreSQL

5.1) J'ai écrit une fonction
utilisateur. Lorsque je l'exécute avec psql, pourquoi
cela finit-il avec un dump core ?

Il peut y avoir plusieurs raisons. Essayez tout d'abord votre
fonction utilisateur dans un programme de test.

5.2) Comment puis-je ajouter de bons nouveaux
types ou fonctions à PostgreSQL ?

Envoyez vos extensions à la liste de diffusion
pgsql-hackers, elles atterriront éventuellement dans
le sous-répertoire contrib/.

5.3) Comment faire pour écrire une
fonction C qui renvoie un tuple ?

Dans les versions de PostgreSQL à partir de 7.3, les
fonctions qui renvoient une table sont totalement supportées
en C, PL/PgSQL, et SQL. Voir le Guide du Programmeur pour plus
d'information. Un exemple de fonction renvoyant une table
définie en C se trouve à
contrib/tablefunc.

5.4) J'ai modifié un fichier source.
Pourquoi ma recompilation ne voit-elle pas les modifications ?

Les Makefiles n'ont pas les dépendances
adéquates pour les fichiers d'en-tête. Il vous faut
faire make clean puis un autre make. Si vous utilisez
GCC, vous pouvez utiliser l'option
--enable-depend de configure pour que le compilateur
calcule les dépendances automatiquement.