Skip to content

Commit

Permalink
Mise à jour en version 9.1.4
Browse files Browse the repository at this point in the history
  • Loading branch information
@gleu
gleu committed Jun 3, 2012
1 parent 4f18333 commit bf988c9
Show file tree
Hide file tree
Showing 14 changed files with 1,529 additions and 149 deletions.
14 changes: 10 additions & 4 deletions postgresql/backup.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1374,10 +1374,6 @@ archive_command = 'local_backup_script.sh "%p" "%f"'
Ainsi toute la complexité est gérée dans le script qui peut être
écrit dans un langage de scripts populaires comme
<application>bash</application> ou <application>perl</application>.
Tout message écrit sur <literal>stderr</literal> à partir du script
apparaîtra dans les journaux applicatifs de la base de données, cela
permettant aux configurations complexes d'être diagnostiquées facilement
en cas d'échec.
</para>
<para>
Quelques exemples de besoins résolus dans
Expand Down Expand Up @@ -1408,6 +1404,16 @@ archive_command = 'local_backup_script.sh "%p" "%f"'
</listitem>
</itemizedlist>
</para>

<tip>
<para>
Lors de l'utilisation du script <varname>archive_command</varname>, il
est préférable d'activer <xref linkend="guc-logging-collector"/>.
Tout message envoyé dans <systemitem>stderr</systemitem> à partir du
script apparaîtra dans les traces du serveur, permettant un diagnostic
plus aisé de configurations complexes en cas de problème.
</para>
</tip>
</sect3>
</sect2>

Expand Down
59 changes: 37 additions & 22 deletions postgresql/config.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2825,10 +2825,8 @@ block : bloc vidé, dirty bloc : bloc à vider ?
planification d'une requête en utilisant une recherche heuristique. Cela
réduit le temps de planification pour les requêtes complexes (celles qui
joignent de nombreuses relations), au prix de plans qui sont quelques
fois inférieurs à ceux trouver par un algorithme exhaustif. De plus, la
recherche de GEQO est aléatoire et les plans peuvent donc varier de
façon non déterministe. Pour plus d'informations, voir <xref
linkend="geqo"/>.
fois inférieurs à ceux trouver par un algorithme exhaustif. Pour plus
d'informations, voir <xref linkend="geqo"/>.
</para>

<variablelist>
Expand Down Expand Up @@ -2867,10 +2865,11 @@ block : bloc vidé, dirty bloc : bloc à vider ?
<literal>FROM</literal> (une construction <literal>FULL OUTER JOIN</literal>
ne compte que pour un élément du <literal>FROM</literal>). La valeur par
défaut est 12. Il est généralement préférable d'utiliser le
planificateur déterministe, exhaustif, pour les requêtes plus simples,
mais pour les requêtes impliquant autant de tables, celui-ci
planificateur standard, exhaustif, pour les requêtes plus simples,
mais pour les requêtes impliquant autant de tables, celui-ci
prend trop de temps, fréquemment plus longtemps que la pénalité dû
à l'exécution d'un plan non optimal.
à l'exécution d'un plan non optimal. Du coup, une limite sur la taille
de la requête est un moyen simple de contrôler l'utilisation de GEQO.
</para>
</listitem>
</varlistentry>
Expand Down Expand Up @@ -3096,7 +3095,7 @@ SELECT * FROM parent WHERE key = 2400;</programlisting>
<para>
Configurer cette valeur à <xref linkend="guc-geqo-threshold"/> ou plus
pourrait déclencher l'utilisation du planificateur GEQO, ce qui pourrait
aboutir à la génération de plans non déterministes. Voir <xref
aboutir à la génération de plans non optimaux. Voir <xref
linkend="runtime-config-query-geqo"/>.
</para>
</listitem>
Expand Down Expand Up @@ -3134,7 +3133,7 @@ SELECT * FROM parent WHERE key = 2400;</programlisting>
<para>
Configurer cette valeur à <xref linkend="guc-geqo-threshold"/> ou plus
pourrait déclencher l'utilisation du planificateur GEQO, ce qui pourrait
aboutir à la génération de plans non déterministes. Voir <xref
aboutir à la génération de plans non optimaux. Voir <xref
linkend="runtime-config-query-geqo"/>.
</para>
</listitem>
Expand Down Expand Up @@ -3185,7 +3184,7 @@ SELECT * FROM parent WHERE key = 2400;</programlisting>
value</quote>), ce qui est bien pratique pour les charger dans des
programmes. Voir <xref linkend="runtime-config-logging-csvlog"/> pour
les détails.
<varname>logging_collector</varname> doit être activé pour produire des
<xref linkend="guc-logging-collector"/> doit être activé pour produire des
journaux applicatifs au format CSV.
</para>

Expand Down Expand Up @@ -3217,26 +3216,42 @@ local0.* /var/log/postgresql
<primary>paramètre de configuration <varname>logging_collector</varname></primary>
</indexterm>
<para>
Ce paramètre capture les messages au format texte et CSV envoyé à
<application>stderr</application> et les redirige dans des journaux
applicatifs. Cette approche est souvent plus utile que la
journalisation avec <application>syslog</application>, car certains
messages peuvent ne pas apparaître dans
<application>syslog</application> (les messages d'échec de l'éditeur de
liens en sont un bon exemple). Ce paramètre ne peut être configuré
qu'au lancement du serveur.
Ce paramètre active le processus <firstterm>logging collector</firstterm>,
qui est un processus en tâche de fond dont le but est de capturer les
traces envoyées sur la sortie des erreurs (<systemitem>stderr</systemitem>)
et de les rediriger vers des fichiers de traces. Cette approche est souvent
plus utile que la journalisation avec <application>syslog</application>,
car certains messages peuvent ne pas apparaître dans
<application>syslog</application>. (Un exemple typique concerne les
messages d'échec de l'éditeur de liens dynamiques&nbsp;; un autre
exemple concerne les messages d'erreurs produits par les scripts comme
celui configuré avec le paramètre <varname>archive_command</varname>.)
Ce paramètre ne peut être configuré qu'au lancement du serveur.
</para>

<note>
<para>
Il est possible d'envoyer les traces sur <systemitem>stderr</systemitem>
sans utiliser le collecteur des traces. Les messages iront à l'endroit
où la sortie des erreurs est dirigée. Néanmoins, cette méthode est
seulement intéressante en cas d'un faible volume de traces car elle ne
propose aucun moyen simple pour réaliser une rotation des journaux
applicatifs. De plus, sur certaines plateformes, ne pas utiliser le
collecteur de traces peut résulter en une perte des traces en sortie
car l'écriture de plusieurs processus sur le même fichier en même temps
peut faire en sorte que certaines écritures soient perdues ou entremêlées.
</para>
</note>

<note>
<para>
Le collecteur des traces est conçu pour ne jamais perdre de
messages. Cela signifie que, dans le cas d'une charge extrêmement
forte, les processus serveur pourraient se trouver bloqués à cause de
forte, les processus serveur pourraient se trouver bloqués lors de
l'envoi de messages de trace supplémentaires. Le collecteur
pourrait accumuler dans ce cas du retard.
<application>syslog</application> préfère supprimer des messages
s'il ne peut pas les écrire. Il est donc moins fiable dans ces cas
mais il ne bloquera pas le reste du système.
<application>syslog</application> préfère ignorer des messages
s'il ne peut pas les écrire, mais il ne bloquera pas le reste du système.
</para>
</note>
</listitem>
Expand Down
2 changes: 1 addition & 1 deletion postgresql/datatype.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -562,7 +562,7 @@
numérique est plus proche de <type>varchar(<replaceable>n</replaceable>)</type> que
de <type>char(<replaceable>n</replaceable>)</type>). Le besoin pour le
stockage réel est de deux octets pour chaque groupe de quatre chiffres
décimaux, plus cinq à huit octets d'en-tête.
décimaux, plus trois à huit octets d'en-tête.
</para>

<indexterm>
Expand Down
11 changes: 2 additions & 9 deletions postgresql/external-projects.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -106,24 +106,17 @@
<entry><ulink url="http://npgsql.projects.postgresql.org/">http://npgsql.projects.postgresql.org/</ulink></entry>
</row>

<row>
<entry>ODBCng</entry>
<entry>ODBC</entry>
<entry>Pilote ODBC alternatif</entry>
<entry><ulink url="http://projects.commandprompt.com/public/odbcng/">http://projects.commandprompt.com/public/odbcng/</ulink></entry>
</row>

<row>
<entry>pgtclng</entry>
<entry>Tcl</entry>
<entry></entry>
<entry><ulink url="http://pgfoundry.org/projects/pgtclng/">http://pgfoundry.org/projects/pgtclng/</ulink></entry>
<entry><ulink url="http://sourceforge.net/projects/pgtclng/">http://sourceforge.net/projects/pgtclng/</ulink></entry>
</row>

<row>
<entry>psqlODBC</entry>
<entry>ODBC</entry>
<entry>Pilote ODBC le plus utilisé</entry>
<entry>Pilote ODBC</entry>
<entry><ulink url="http://psqlodbc.projects.postgresql.org/">http://psqlodbc.projects.postgresql.org/</ulink></entry>
</row>

Expand Down
110 changes: 47 additions & 63 deletions postgresql/func.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -3436,20 +3436,13 @@ cast(-44 as bit(12)) <lineannotation>111111010100</lineannotation>
lui-même, on écrit deux fois ce caractère.
</para>

<para>
L'antislash a déjà une signification particulière dans les
chaînes littérales. De ce fait, pour écrire un motif qui contient un
antislash, il faut écrire deux antislashs dans l'instruction SQL (en
supposant que la syntaxe d'échappement de chaînes soit utilisée, voir
<xref linkend="sql-syntax-strings"/>). Ainsi, pour écrire un motif
qui corresponde effectivement à un antislash littéral nécessite l'écriture
de quatre antislash dans l'instruction. Tout cela peut être évité en
sélectionnant un autre caractère d'échappement avec
<literal>ESCAPE</literal>&nbsp;; un antislash n'est alors plus spécial
au regard de <function>LIKE</function> (mais il est toujours spécial pour
l'analyseur de chaînes littérales, et nécessite toujours d'être doublé
pour correspondre à un antislash).
</para>
<note>
<para>
Si vous avez désactivé <xref linkend="guc-standard-conforming-strings"/>,
tout antislash écrit dans des chaînes litérales devra être doublé. Voir
<xref linkend="sql-syntax-strings"/> pour plus d'informations.
</para>
</note>

<para>
Il est aussi possible de ne sélectionner aucun caractère d'échappement en
Expand Down Expand Up @@ -3782,10 +3775,8 @@ substring('foubar' from 'o(.)b') <lineannotation>u</lineannotation></programli
sous-chaîne source correspondante doit être insérée. Elle peut aussi
contenir <literal>\&amp;</literal> pour indiquer que la sous-chaîne
qui correspond au motif entier doit être insérée. On écrit
<literal>\\</literal> pou placer un antislash littéral dans
le texte de remplacement (comme toujours, les
antislashs doivent être doublés dans les libellés, si la syntaxe
d'échappement de chaînes est utilisée).
<literal>\\</literal> pour placer un antislash littéral dans
le texte de remplacement.
Le paramètre
<replaceable>options</replaceable> est une chaîne optionnelle de drapeaux
(0 ou plus) d'une lettre qui modifie le comportement de la fonction. Le
Expand Down Expand Up @@ -4124,17 +4115,14 @@ une affaiblissement conceptuel du message original lors de sa traduction... -->
</table>

<para>
Une ER ne peut pas se terminer par <literal>\</literal>.
Une ER ne peut pas se terminer par un antislash (<literal>\</literal>).
</para>

<note>
<para>
L'antislash (<literal>\</literal>) a déjà une
signification particulière dans les chaînes littérales
<productname>PostgreSQL</productname>. Pour écrire un motif contenant un
antislash, il faut écrire deux antislashs dans l'instruction, en supposant
que la syntaxe de chaîne d'échappement est utilisée (voir <xref
linkend="sql-syntax-strings"/>).
Si vous avez désactivé <xref linkend="guc-standard-conforming-strings"/>,
tout antislash écrit dans des chaîntes litérales devra être doublé. Voir
<xref linkend="sql-syntax-strings"/> pour plus d'informations.
</para>
</note>

Expand Down Expand Up @@ -5754,11 +5742,8 @@ MON')</literal> renvoie une erreur car <function>to_timestamp</function>
<listitem>
<para>
pour afficher un guillemet double dans la sortie, il faut le faire
précéder d'un antislash. <literal>E'\\"YYYY
Month\\"'</literal>, par exemple. <!-- "" font-lock sanity :-) -->
(Deux antislashs sont nécessaire parce que l'antislash a
déjà une signification spéciale lors de l'utilisation de la syntaxe
d'échappement des chaînes)&nbsp;;
précéder d'un antislash. <literal>'\"YYYY
Month\"'</literal>, par exemple. <!-- "" font-lock sanity :-) -->
</para>
</listitem>

Expand Down Expand Up @@ -15235,7 +15220,7 @@ SELECT (pg_stat_file('nomfichier')).modification;</programlisting>
<literal><function>pg_advisory_xact_lock_shared(<parameter>key1</parameter> <type>int</type>, <parameter>key2</parameter> <type>int</type>)</function></literal>
</entry>
<entry><type>void</type></entry>
<entry>Obtient un verrou consultatif partagé au niveau transaction pour la transaction courante</entry>
<entry>Obtient un verrou consultatif partagé au niveau transaction</entry>
</row>
<row>
<entry>
Expand Down Expand Up @@ -15305,8 +15290,7 @@ SELECT (pg_stat_file('nomfichier')).modification;</programlisting>
<function>pg_advisory_lock</function> verrouille une ressource applicative
qui peut être identifiée soit par une valeur de clé sur 64
bits soit par deux valeurs de clé sur 32 bits (les deux espaces
de clé ne se surchargent pas). The key type is specified in
<literal>pg_locks.objid</literal>.
de clé ne se surchargent pas).
Si une autre session détient déjà un verrou
sur la même ressource, la fonction attend que la ressource
devienne disponible. Le verrou est exclusif. Les demandes de verrou
Expand Down Expand Up @@ -15345,6 +15329,36 @@ SELECT (pg_stat_file('nomfichier')).modification;</programlisting>
un verrou partagé au lieu d'un verrou exclusif.
</para>

<indexterm>
<primary>pg_advisory_unlock</primary>
</indexterm>
<para>
<function>pg_advisory_unlock</function> relâche un verrou
exclusif précédemment acquis au niveau session. Elle retourne <literal>true</literal> si le
verrou est relaché avec succès. Si le verrou n'était pas détenu,
<literal>false</literal> est renvoyé et un message d'avertissement
SQL est émis par le serveur.
</para>

<indexterm>
<primary>pg_advisory_unlock_shared</primary>
</indexterm>
<para>
<function>pg_advisory_unlock_shared</function> fonctionne de la même façon
que <function>pg_advisory_unlock</function> mais pour relâcher un verrou
partagé au niveau session.
</para>

<indexterm>
<primary>pg_advisory_unlock_all</primary>
</indexterm>
<para>
<function>pg_advisory_unlock_all</function> relâche tous les verrous
consultatifs au niveau session détenus par la session courante. (Cette fonction est appelée
implicitement à la fin de la session, même si le client se déconnecte
brutalement.)
</para>

<indexterm>
<primary>pg_advisory_xact_lock</primary>
</indexterm>
Expand Down Expand Up @@ -15386,36 +15400,6 @@ SELECT (pg_stat_file('nomfichier')).modification;</programlisting>
façon explicite.
</para>

<indexterm>
<primary>pg_advisory_unlock</primary>
</indexterm>
<para>
<function>pg_advisory_unlock</function> relâche un verrou
exclusif précédemment acquis au niveau session. Elle retourne <literal>true</literal> si le
verrou est relaché avec succès. Si le verrou n'était pas détenu,
<literal>false</literal> est renvoyé et un message d'avertissement
SQL est émis par le serveur.
</para>

<indexterm>
<primary>pg_advisory_unlock_shared</primary>
</indexterm>
<para>
<function>pg_advisory_unlock_shared</function> fonctionne de la même façon
que <function>pg_advisory_unlock</function> mais pour relâcher un verrou
partagé au niveau session.
</para>

<indexterm>
<primary>pg_advisory_unlock_all</primary>
</indexterm>
<para>
<function>pg_advisory_unlock_all</function> relâche tous les verrous
consultatifs au niveau session détenus par la session courante. (Cette fonction est appelée
implicitement à la fin de la session, même si le client se déconnecte
brutalement.)
</para>

</sect1>

<sect1 id="functions-trigger">
Expand Down

0 comments on commit bf988c9

Please sign in to comment.