| Documentation PostgreSQL 8.0.25 | ||||
|---|---|---|---|---|
| Pr�c�dent | Arri�re rapide | Avance rapide | Suivant | |
PostgreSQL utilise un protocole messages pour la communication entre les clients et les serveurs (<<�frontend�>> et <<�backend�>>). Le protocole est support� par TCP/IP et par les sockets de domaine Unix. Le num�ro de port 5432 a �t� enregistr� par l'IANA comme num�ro de port TCP personnalis� pour les serveurs supportant ce protocole mais en pratique tout num�ro de port non privil�gi� peut �tre utilis�.
Ce document d�crit la version 3.0 de ce protocole, telle qu'implant�e dans PostgreSQL depuis la version 7.4. Pour obtenir la description des versions pr�c�dentes du protocole, il faudra se reporter aux versions ant�rieures de la documentation de PostgreSQL. Un m�me serveur peut supporter plusieurs versions du protocole. Lors de l'�tablissement de la communication le client indique au serveur la version du protocole qu'il souhaite utiliser. Le serveur suivra ce protocole s'il en est capable.
Les fonctionnalit�s de haut niveau construites sur ce protocole (par exemple, la fa�on dont libpq passe certaines variables d'environnement � l'�tablissement de la connexion) ne sont pas couvertes par ce chapitre.
Pour r�pondre efficacement � de multiples clients, le serveur lance un nouveau serveur (<<�backend�>>) pour chaque client. Dans l'impl�mentation actuelle, un nouveau processus fils est cr�� imm�diatement apr�s la d�tection d'une connexion entrante. Et cela de fa�on transparente pour le protocole. Pour le protocole, les termes <<�backend�>> et <<�serveur�>> sont interchangeables ; comme <<�frontend�>>, <<�interface�>> et <<�client�>>.
Le protocole utilise des phases distinctes pour le lancement et le fonctionnement habituel. Dans la phase de lancement, le client ouvre une connexion au serveur et s'authentifie. (Ce qui peut impliquer un message simple, ou plusieurs messages, en fonction de la m�thode d'authentification utilis�e.) En cas de r�ussite, le serveur envoie une information de statut au client et entre dans le mode normal de fonctionnement. Exception faite du message initial de demande de lancement, cette partie du protocole est conduite par le serveur.
En mode de fonctionnement normal, le client envoie requ�tes et commandes au serveur et celui-ci retourne les r�sultats de requ�tes et autres r�ponses. Il existe quelques cas (comme NOTIFY) pour lesquels le serveur enverra des messages non sollicit�s. Mais dans l'ensemble, cette partie de la session est conduite par les requ�tes du client.
En g�n�ral, c'est le client qui d�cide de la cl�ture de la session. Il arrive, cependant, qu'elle soit forc�e par le moteur. Dans tous les cas, lors de la fermeture de la connexion par le serveur, toute transaction ouverte (non termin�e) sera annul�e.
En mode op�rationnel normal, les commandes SQL peuvent �tre ex�cut�es via deux sous-protocoles. Dans le protocole des <<�requ�tes simples�>>, le client envoie juste une cha�ne, la requ�te, qui est analys�e et ex�cut�e imm�diatement par le serveur. Dans le protocole des <<�requ�tes �tendues�>>, le traitement des requ�tes est d�coup� en de nombreuses �tapes : l'analyse, le lien avec les valeurs de param�tres et l'ex�cution. Ceci offre flexibilit� et gains en performances au prix d'une complexit� suppl�mentaire.
Le mode op�rationnel normal offre des sous-protocoles suppl�mentaires pour certaines op�rations comme COPY.
Toute la communication s'effectue au travers d'un flux de messages. Le premier octet d'un message identifie le type de message et les quatre octets suivants sp�cifient la longueur du reste du message (cette longueur inclut les 4 octets de longueur, mais pas l'octet du type de message). Le reste du contenu du message est d�termin� par le type de message. Pour des raisons historiques, le tout premier message envoy� par le client (le message de lancement) n'a pas l'octet initial de type du message.
Pour �viter de perdre la synchronisation avec le flux de messages, le serveur et le client stocke le message complet dans un tampon (en utilisant le nombre d'octets) avant de tenter de traiter son contenu. Cela permet une r�cup�ration simple si une erreur est d�tect�e lors du traitement du contenu. Dans les situations extr�mes (telles que de ne pas avoir assez de m�moire pour placer le message dans le tampon), le r�cepteur peut utiliser le nombre d'octets pour d�terminer le nombre d'entr�es � ignorer avant de continuer la lecture des messages.
En revanche, serveurs et clients doivent �tre attentifs � ne pas envoyer de message incomplet. Ceci est habituellement obtenu en pla�ant le message complet dans un tampon avant de commencer l'envoi. Si un �chec de communications survient pendant l'envoi ou la r�ception d'un message, la seule r�ponse plausible est l'abandon de la connexion. Il y a, en effet, peu d'espoir de resynchronisation des messages.
Dans le protocole des requ�tes �tendues, l'ex�cution de commandes SQL est scind�e en plusieurs �tapes. L'�tat retenu entre les �tapes est repr�sent� par deux types d'objets : les instructions pr�par�es et les portails. Une instruction pr�par�e repr�sente le r�sultat de l'analyse syntaxique, de l'analyse s�mantique et de la planification d'une cha�ne de requ�te textuelle. Une instruction pr�par�e n'est pas n�cessairement pr�te � �tre ex�cut�e parce qu'il peut lui manquer certaines valeurs de param�tres. Un portail repr�sente une instruction pr�te � �tre ex�cut�e ou d�j� partiellement ex�cut�e, dont toutes les valeurs de param�tres manquant sont donn�es. (Pour les instructions SELECT, un portail est �quivalent � un curseur ouvert. Il est choisi d'utiliser un terme diff�rent car les curseurs ne g�rent pas les instructions autres que SELECT.)
Le cycle d'ex�cution complet consiste en une �tape d'analyse syntaxique, qui cr�e une instruction pr�par�e � partir d'une cha�ne de requ�te textuelle ; une �tape de liaison, qui cr�e un portail � partir d'une instruction pr�par�e et des valeurs pour les param�tres n�cessaires ; et une �tape d'ex�cution qui ex�cute une requ�te du portail. Dans le cas d'une requ�te qui renvoie des lignes (SELECT, SHOW, etc), il peut �tre signal� � l'�tape d'ex�cution que seul un certain nombre de lignes doivent �tre retourn�es, de sorte que de multiples �tapes d'ex�cution seront n�cessaires pour terminer l'op�ration.
Le serveur peut garder la trace de multiples instructions pr�par�es et portails (qui n'existent qu'� l'int�rieur d'une session, et ne sont jamais partag�s entre les sessions). Les instructions pr�par�es et les portails sont r�f�renc�s par les noms qui leur sont affect�s � la cr�ation. De plus, il existe une instruction pr�par�e et un portail <<�non nomm�s�>>. Bien qu'ils se comportent comme des objets nomm�s, les op�rations y sont optimis�es en vue d'une ex�cution unique de la requ�te avant son annulation puis est annul�e. En revanche, les op�rations sur les objets nomm�s sont optimis�es pour des utilisations multiples.
Les donn�es d'un type particulier pouvaient �tre transmises sous diff�rents formats. Depuis PostgreSQL 7.4, les seuls formats support�s sont le <<�texte�>> et le <<�binaire�>> mais le protocole pr�voit des extensions futures. Le format d�sir� pour toute valeur est sp�cifi� par un code de format. Les clients peuvent sp�cifier un code de format pour chaque valeur de param�tre transmise et pour chaque colonne du r�sultat d'une requ�te. Le texte a z�ro pour code de format z�ro, le binaire un. Tous les autres codes de format sont r�serv�s pour des d�finitions futures.
La repr�sentation au format texte des valeurs est toute cha�ne produite et accept�e par les fonctions de conversion en entr�e/sortie pour le type de donn�es particulier. Dans la repr�sentation transmise, il n'y a pas de caract�re nul de terminaison de cha�ne ; le client doit en ajouter un s'il souhaite traiter les valeurs comme des cha�nes C (le format texte n'autorise pas les valeurs nulles int�gr�es).
Les repr�sentations binaires des entiers utilisent l'ordre d'octet r�seau (octet le plus significatif en premier). Pour les autres types de donn�es, il faudra consulter la documentation ou le code source pour conna�tre la repr�sentation binaire. Les repr�sentations binaires des types de donn�es complexes changent parfois entre les versions du serveur ; le format texte reste le choix le plus portable.
| Pr�c�dent | Sommaire | Suivant |
| pg_views | Niveau sup�rieur | Flux de messages |