Skip to content

Commit

Permalink
Mise à jour en version 10.7
Browse files Browse the repository at this point in the history
  • Loading branch information
@gleu
gleu committed Feb 15, 2019
1 parent 79f66d4 commit 6767e18
Show file tree
Hide file tree
Showing 47 changed files with 1,592 additions and 134,856 deletions.
96 changes: 69 additions & 27 deletions postgresql/config.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5026,35 +5026,15 @@ local0.* /var/log/postgresql

<variablelist>

<varlistentry id="guc-client-min-messages" xreflabel="client_min_messages">
<term><varname>client_min_messages</varname> (<type>enum</type>)</term>
<listitem>
<indexterm>
<primary>paramètre de configuration <varname>client_min_messages</varname></primary>
</indexterm>
<para>
Contrôle les niveaux de message envoyés au client. Les valeurs
valides sont <literal>DEBUG5</literal>,
<literal>DEBUG4</literal>, <literal>DEBUG3</literal>, <literal>DEBUG2</literal>,
<literal>DEBUG1</literal>, <literal>LOG</literal>, <literal>NOTICE</literal>,
<literal>WARNING</literal>, <literal>ERROR</literal>, <literal>FATAL</literal>,
et <literal>PANIC</literal>. Chaque niveau inclut tous les
niveaux qui le suivent. Plus on progresse dans la liste,
plus le nombre de messages envoyés est faible. <literal>NOTICE</literal>
est la valeur par défaut. <literal>LOG</literal> a ici une portée
différente de celle de <varname>log_min_messages</varname>.
</para>
</listitem>
</varlistentry>

<varlistentry id="guc-log-min-messages" xreflabel="log_min_messages">
<term><varname>log_min_messages</varname> (<type>enum</type>)</term>
<listitem>
<indexterm>
<primary>paramètre de configuration <varname>log_min_messages</varname></primary>
</indexterm>
<para>
Contrôle les niveaux de message écrits dans les traces du serveur.
Contrôle les <link linkend="runtime-config-severity-levels">niveaux de
message</link> écrits dans les traces du serveur.
Les valeurs valides sont <literal>DEBUG5</literal>, <literal>DEBUG4</literal>,
<literal>DEBUG3</literal>, <literal>DEBUG2</literal>, <literal>DEBUG1</literal>,
<literal>INFO</literal>, <literal>NOTICE</literal>, <literal>WARNING</literal>,
Expand All @@ -5063,7 +5043,7 @@ local0.* /var/log/postgresql
suivent. Plus on progresse dans la liste, plus le nombre de messages
envoyés est faible. <literal>WARNING</literal> est la valeur par
défaut. <literal>LOG</literal> a ici une portée différente de celle
de <varname>client_min_messages</varname>. Seuls les superutilisateurs peuvent
de <xref linkend="guc-client-min-messages"/>. Seuls les superutilisateurs peuvent
modifier la valeur de ce paramètre.
</para>
</listitem>
Expand All @@ -5078,9 +5058,9 @@ local0.* /var/log/postgresql
<para>
Contrôle si l'instruction SQL à l'origine d'une erreur doit être
enregistrée dans les traces du serveur. L'instruction SQL en cours est
incluse dans les traces pour tout message de sévérité indiquée ou
supérieure. Les valeurs valides sont
<literal>DEBUG5</literal>,
incluse dans les traces pour tout message de <link
linkend="runtime-config-severity-levels">sévérité</link> indiquée ou
supérieure. Les valeurs valides sont <literal>DEBUG5</literal>,
<literal>DEBUG4</literal>, <literal>DEBUG3</literal>,
<literal>DEBUG2</literal>, <literal>DEBUG1</literal>,
<literal>INFO</literal>, <literal>NOTICE</literal>,
Expand Down Expand Up @@ -6391,6 +6371,32 @@ Ces paramètres contrôlent le comportement de la fonctionnalité appelée
<title>Comportement des instructions</title>
<variablelist>

<varlistentry id="guc-client-min-messages" xreflabel="client_min_messages">
<term><varname>client_min_messages</varname> (<type>enum</type>)</term>
<listitem>
<indexterm>
<primary>paramètre de configuration <varname>client_min_messages</varname></primary>
</indexterm>
<para>
Contrôle les <link linkend="runtime-config-severity-levels">niveaux de
message</link> envoyés au client. Les valeurs valides sont
<literal>DEBUG5</literal>, <literal>DEBUG4</literal>,
<literal>DEBUG3</literal>, <literal>DEBUG2</literal>,
<literal>DEBUG1</literal>, <literal>LOG</literal>,
<literal>NOTICE</literal>, <literal>WARNING</literal> et
<literal>ERROR</literal>. Chaque niveau inclut tous les
niveaux qui le suivent. Plus on progresse dans la liste,
plus le nombre de messages envoyés est faible. <literal>NOTICE</literal>
est la valeur par défaut. <literal>LOG</literal> a ici une portée
différente de celle de <varname>log_min_messages</varname>.
</para>
<para>
Les messages de niveau <literal>INFO</literal> sont toujours envoyés au
client.
</para>
</listitem>
</varlistentry>

<varlistentry id="guc-search-path" xreflabel="search_path">
<term><varname>search_path</varname> (<type>string</type>)</term>
<listitem>
Expand Down Expand Up @@ -6419,7 +6425,7 @@ Ces paramètres contrôlent le comportement de la fonctionnalité appelée
<para>
Si un des éléments de la liste est le nom spécial <literal>$user</literal>,
alors le schéma dont le nom correspond à la valeur retournée par
<function>SESSION_USER</function> est substitué, s'il existe et que
<function>CURRENT_USER</function> est substitué, s'il existe et que
l'utilisateur ait le droit <literal>USAGE</literal> sur ce schéma
(sinon <literal>$user</literal> est ignoré).
</para>
Expand Down Expand Up @@ -8074,6 +8080,42 @@ SET XML OPTION { DOCUMENT | CONTENT };
</listitem>
</varlistentry>

<varlistentry id="guc-data-sync-retry" xreflabel="data_sync_retry">
<term><varname>data_sync_retry</varname> (<type>boolean</type>)
<indexterm>
<primary>paramètre de configuration <varname>data_sync_retry</varname></primary>
</indexterm>
</term>
<listitem>
<para>
Lorsqu'il est configuré à false, ce qui est la valeur par défaut,
<productname>PostgreSQL</productname> lèvera une erreur de niveau PANIC
en cas d'échec de synchronisation des fichiers de données modifiés sur
le système de fichiers. Ceci causera le crash du serveur de bases de
données.
</para>
<para>
Sur certains systèmes d'exploitation, le statut des données dans le
cache disque du noyau n'est pas connu après un échec de synrhconisation.
Dans certains cas, ce statut peut être entièrement oublié, rendant
risquée toute nouvelle tentative. La deuxième tentative pourrait être
rapportée comme réussi alors qu'en fait la donnée a été perdue. Dans ces
circonstances, la seule façon d'éviter une perte de données est de
rejouer les journaux de transactions après chaque statut d'échec, de
préférence après une investigation sur la cause originale de l'échec et
de remplacer tout matériel défectueux.
</para>
<para>
S'il est configuré à true, <productname>PostgreSQL</productname>
renverra une erreur mais continuera à s'exécuter pour que l'opération de
synchronisation sur disque soit tentée de noueau au prochain checkpoint.
Il faut le configurer à true après avoir investigué sur le traitement
par le système d'exploitation des données en cache dans le cas d'un
échec de synchronisation.
</para>
</listitem>
</varlistentry>

</variablelist>

</sect1>
Expand Down
11 changes: 7 additions & 4 deletions postgresql/custom-scan.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -42,10 +42,13 @@
<title>Créer des parcours de chemin personnalisés</title>

<para>
Un module de parcours personnalisé ajoutera classiquement des chemins
pour une relation de base en mettant en place le hook suivant, qui est
appelé après que le code de base ait généré ce qu'il pense être
l'ensemble complet et correct des chemins d'accès pour la relation.
Un module de parcours personnalisé ajoutera classiquement des chemins pour
une relation de base en mettant en place le hook suivant, qui est appelé
après que le code de base ait généré tous les chemins d'accès possibles
pour la relation (sauf les chemins Gather, qui sont réalisés après cet
appel pour qu'ils puissent utiliser les chemins partiels ajoutés par le
hook&nbsp;:

<programlisting>
typedef void (*set_rel_pathlist_hook_type) (PlannerInfo *root,
RelOptInfo *rel,
Expand Down
75 changes: 34 additions & 41 deletions postgresql/datatype.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1398,17 +1398,16 @@ SELECT b, char_length(b) FROM test2;
Le format <quote>hex</quote> code les données binaires sous la forme de
deux chiffres hexadécimaux par octet, le plus significatif en premier. La
chaîne complète est précédée par la séquence <literal>\x</literal> (pour
la distinguer du format d'échappement). Dans la majorité des cas
(exactement les mêmes pour lesquels les antislashs sont doublés dans le
format d'échappement), l'antislash initial peut avoir besoin d'être
échappé par un doublage du caractère&nbsp;; les détails sont disponibles
plus bas. Les chiffres hexadécimaux peuvent être soit en majuscules, soit
en minuscules, et les espaces blancs sont permis entre les paires de
chiffres (mais pas à l'intérieur d'une paire ni dans la séquence
<literal>\x</literal> de début). Le format hexadécimal est compatible avec
une grande variété d'applications et de protocoles externes, et il a
tendance à être plus rapide à convertir que le format d'échappement. Son
utilisation est donc préférée.
la distinguer du format d'échappement). Dans certains cas, l'antislash
initial peut avoir besoin d'être échappé par un doublage du caractère
(voir <xref linkend="sql-syntax-strings"/>). En saisie, les chiffres
hexadécimaux peuvent être soit en majuscules, soit en minuscules, et les
espaces blancs sont permis entre les paires de chiffres (mais pas à
l'intérieur d'une paire ni dans la séquence <literal>\x</literal> de
début). Le format hexadécimal est compatible avec une grande variété
d'applications et de protocoles externes, et il a tendance à être plus
rapide à convertir que le format d'échappement. Son utilisation est donc
préférée.
</para>

<para>
Expand Down Expand Up @@ -1444,9 +1443,8 @@ SELECT '\xDEADBEEF';
être échappés alors que les autres valeurs d'octets
<emphasis>peuvent</emphasis> être échappés. En général, pour échapper un
octet, il suffit de le convertir dans sa valeur octale composée de trois
chiffres et de la faire précéder d'un antislash (ou de deux antislashs s'il
faut utiliser la syntaxe d'échappement de chaînes). L'antislash lui-même
(octet décimale 92) peut alternativement être représenté par un double antislash.
chiffres et de la faire précéder d'un antislash. L'antislash lui-même
(octet décimal 92) peut alternativement être représenté par un double antislash.
Le <xref linkend="datatype-binary-sqlesc"/>
affiche les caractères qui doivent être échappés et donne les séquences
d'échappement possibles.
Expand All @@ -1461,7 +1459,7 @@ SELECT '\xDEADBEEF';
<entry>Description</entry>
<entry>Représentation échappée en entrée</entry>
<entry>Exemple</entry>
<entry>Représentation en sortie</entry>
<entry>Représentation hexadécimale</entry>
</row>
</thead>

Expand All @@ -1485,7 +1483,7 @@ SELECT '\xDEADBEEF';
<row>
<entry>92</entry>
<entry>antislash</entry>
<entry><literal>'\'</literal> ou <literal>'\\134'</literal></entry>
<entry><literal>'\\'</literal> ou <literal>'\134'</literal></entry>
<entry><literal>SELECT '\\'::bytea;</literal></entry>
<entry><literal>\x5c</literal></entry>
</row>
Expand All @@ -1503,34 +1501,29 @@ SELECT '\xDEADBEEF';
</table>

<para>
La nécessité d'échapper les octets <emphasis>non affichables</emphasis> dépend
des paramétrages de la locale. Il est parfois possible de s'en sortir sans
échappement. Le résultat de chacun des
exemples du <xref linkend="datatype-binary-sqlesc"/> fait exactement
un octet, même si la représentation en sortie fait plus d'un caractère.
La nécessité d'échapper les octets <emphasis>non affichables</emphasis>
dépend des paramétrages de la locale. Il est parfois possible de s'en
sortir sans échappement.
</para>

<para>
S'il faut écrire tant d'antislashs, comme
indiqué dans le <xref linkend="datatype-binary-sqlesc"/>, c'est qu'une
chaîne binaire doit passer à travers deux phases d'analyse dans le
serveur <productname>PostgreSQL</productname>. Le premier antislash
de chaque paire est vu comme un caractère d'échappement par
l'analyseur de chaîne (en supposant que la syntaxe d'échappement des
chaînes soit utilisée) et est donc consommé, laissant le second antislash
de la paire. (Les chaînes à guillemets dollar peuvent être utilisées
pour éviter ce niveau d'échappement.) L'antislash restant est
compris par la fonction d'entrée de <productname>PostgreSQL</productname>
comme le début d'une valeur octale sur trois caractères ou comme
l'échappement d'un autre antislash.
Par exemple, une chaîne littérale passée au serveur comme
<literal>'\001'</literal> devient <literal>\001</literal> après
être passée au travers de l'analyseur d'échappement de chaîne.
Le <literal>\001</literal> est envoyé à la fonction d'entrée de
<type>bytea</type>, qui le convertit en un octet simple ayant une valeur
décimale de 1. Le guillemet simple n'est pas traité
spécialement par <type>bytea</type> et suit les règles normales
des chaînes littérales de chaîne. Voir aussi la <xref linkend="sql-syntax-strings"/>.
La raison pour laquelle les guillemets simples doivent être doublés, comme
indiqué dans <xref linkend="datatype-binary-sqlesc"/>, est que cela est
vrai pour toute chaîne litérale dans une commande SQL. L'analyseur
générique des chaînes litérales utilise les guillemets simples externes et
réduit toute paire de guillemets simples en un seul caractère. La fonction
en entrée du type <type>bytea</type> ne voit qu'un guillemet simple, qu'il
traire comme un caractère standard. Néanmoins, la fonction en entrée du
type <type>bytea</type> traite les antislashs de façon spéciale et les
autres comportements montrés dans <xref linkend="datatype-binary-sqlesc"/>
sont implémentés par cette fonction.
</para>

<para>
Dans certains contextes, les antislashs doivent être doublés par rapport à
ce qui est montré ci-dessus car l'analyseur générique de chaîne litérale
réduira aussi les paires d'antislashs en un seul caractère de
données&nbsp;; voir <xref linkend="sql-syntax-strings"/>.
</para>

<para>
Expand Down
91 changes: 84 additions & 7 deletions postgresql/datetime.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -23,8 +23,8 @@
<title>Interprétation des Date/Heure saisies</title>

<para>
Les entrées de type date/heure sont toutes décodées en utilisant le processus
suivant.
Les chaînes en entrée de type date/heure sont décodées en utilisant le
processus suivant.
</para>

<procedure>
Expand Down Expand Up @@ -77,21 +77,22 @@

<step>
<para>
Si le lexème est une chaîne texte, le comparer avec les différentes chaînes
possibles&nbsp;:
Si le lexème est une chaîne texte alphabétique, le comparer avec les
différentes chaînes possibles&nbsp;:
</para>

<substeps>
<step>
<para>
Faire une recherche binaire dans la table pour vérifier si le lexème
est une abréviation de fuseau horaire.
Vérifier si le jeton correspond à une abréviation connue d'un fuseau
horaire. Ces abréviations sont fournies par le fichier de configuration
décrit dans <xref linkend="datetime-config-files"/>.
</para>
</step>

<step>
<para>
S'il n'est pas trouvé, une recherche binaire est effectuée dans la table
S'il n'est pas trouvé, rechercher dans la table interne
pour vérifier si le lexème est une chaîne spéciale
(<literal>today</literal>, par exemple),
un jour (<literal>Thursday</literal>, par exemple),
Expand Down Expand Up @@ -194,6 +195,82 @@
</sect1>


<sect1 id="datetime-invalid-input">
<title>Gestion des horodatages ambigus ou invalides</title>

<para>
D'ordinaire, si une chaîne date/heure est syntaxiquement valide mais
contient des valeurs de champs hors de l'intervalle, une erreur sera
renvoyée. Par exemple, une entrée indiquant le 31 février sera rejetée.
</para>

<para>
Lors d'un changement d'heure, il est possible qu'une chaîne apparemment
valide représente un horodatage inexistant ou ambigu. Ce genre de cas n'est
pas rejeté. L'ambiguité est résolue en déterminant le décalage UTC à
appliquer. Par exemple, supposons que le paramètre
<xref linkend="guc-timezone"/> est configuré à
<literal>America/New_York</literal>&nbsp;:
<programlisting>
=&gt; SELECT '2018-03-11 02:30'::timestamptz;
timestamptz
------------------------
2018-03-11 03:30:00-04
(1 row)
</programlisting>
Comme ce jour était une transition vers l'avant pour ce fuseau horaire,
l'heure 2:30AM n'existe pas&nbsp;; les horloges passent directement de 2h
à 3h EDT. <productname>PostgreSQL</productname> interpréte l'heure donnée
comme s'il s'agissait de l'heure standard (UTC-5), qui se décline donc en
3:30 EDT (UTC-4).
</para>

<para>
De la même façon, prenons en considération ce comportement lors d'une
transition en arrière&nbsp;:
<programlisting>
=&gt; SELECT '2018-11-04 02:30'::timestamptz;
timestamptz
------------------------
2018-11-04 02:30:00-05
(1 row)
</programlisting>
À cette date, il existe deux interprétations possibles de 2:30AM&nbsp;;
soit 2:30AM EDT, soit une heure après la transition, 2:30AM EST.
De nouveau, <productname>PostgreSQL</productname> interpète l'heure donnée
comme s'il s'agissait de l'heure standard (UTC-5). Nous ouvons forcer
l'interprétation en spécifiant le temps et sa règle de conversion&nbsp;:
<programlisting>
=&gt; SELECT '2018-11-04 02:30 EDT'::timestamptz;
timestamptz
------------------------
2018-11-04 01:30:00-05
(1 row)
</programlisting>
Cet horodatage peut être interprété soit comme 2:30 UTC-4 soit comme
1:30 UTC-5&nbsp;; le code de sortie de l'horodatage a choisi ce dernier.
</para>

<para>
La règle précise qui se trouve appliquée dans de tels cas est qu'un
horodatage invalide qui semble survenir pendant une transition vers
l'avant est affecté au décalage UTC qui prévaut dans le fuseau horaire
juste avant la transition alors qu'un horodatage ambigu qui semble
survenir pendant une transition vers l'arrière se voit affecté le décalage
UTC qui prévaut juste après la transition. Dans la plupart des fuseaux
horaires, ceci est équivalent à dire que <quote>l'interprétation du temps
standard est préféré lorsqu'il y a un doute</quote>.
</para>

<para>
Dans tous les cas, le décalage UTC associé à un horodatage peut être
spécifié explicitement, en utilisant soit un décalage numérique UTC ou une
abréviation de fuseau horaire correspondent au décalage TUC fixé. La règle
donnée s'applique seulement si nécessaire pour convertir un décalage UTC
pour un fuseau horaire pour lequel le décalage varie.
</para>
</sect1>

<sect1 id="datetime-keywords">
<title>Mots clés Date/Heure</title>

Expand Down

0 comments on commit 6767e18

Please sign in to comment.