Skip to content

Commit

Permalink
Mise à jour en version 13.2
Browse files Browse the repository at this point in the history
  • Loading branch information
@gleu
gleu committed Feb 17, 2021
1 parent b015e47 commit c955306
Show file tree
Hide file tree
Showing 39 changed files with 5,648 additions and 3,620 deletions.
45 changes: 26 additions & 19 deletions postgresql/arch-dev.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -547,25 +547,32 @@
<command>INSERT</command>, <command>UPDATE</command> et
<command>DELETE</command>. Pour <command>SELECT</command>, le code de
l'exécuteur de plus haut niveau a uniquement besoin d'envoyer chaque ligne
retournée par l'arbre plan de la requête vers le client. Pour
<command>INSERT</command>, chaque ligne renvoyée est insérée dans la table cible
indiquée par <command>INSERT</command>. Cela se fait dans un n&oelig;ud
spécial haut niveau du plan appelé <literal>ModifyTable</literal>. (Une
simple commande <command>INSERT ... VALUES</command> crée un arbre plan trivial
constitué d'un seul n&oelig;ud, <literal>Result</literal>, calculant une
seule ligne de résultat, et <literal>ModifyTable</literal> au-dessus pour
réaliser l'insertion.
Mais <command>INSERT ... SELECT</command> peut demander la pleine puissance du
mécanisme de l'exécuteur.) Pour <command>UPDATE</command>, le planificateur
s'arrange pour que chaque ligne calculée inclue toutes les valeurs mises à
jour des colonnes, plus le <firstterm>TID</firstterm> (tuple ID ou
l'identifiant de la ligne) de la ligne de la cible originale&nbsp;; cette
donnée est envoyée dans un n&oelig;ud <literal>ModifyTable</literal>, qui
utilise l'information pour créer une nouvelle ligne mise à jour et
marquer l'ancienne ligne comme supprimée. Pour <command>DELETE</command>,
la seule colonne renvoyée par le plan est le TID, et <literal>ModifyTable</literal>
node utilise simplement le TID pour visiter chaque ligne cible et la
marquer comme supprimée.
retournée par l'arbre plan de la requête vers le client. <command>INSERT
... SELECT</command>, <command>UPDATE</command>, and
<command>DELETE</command> sont en réalité des <command>SELECT</command>
sous un nœud de plan haut niveau appelé <literal>ModifyTable</literal>.
</para>

<para>
<command>INSERT ... SELECT</command> remplit les lignes de
<literal>ModifyTable</literal> pour insertion. Pour
<command>UPDATE</command>, l'optimiseur s'arrange pour que chaque ligne
traitée inclut toutes les valeurs mises à jour des colonnes, plus le
<firstterm>TID</firstterm> (<foreignphrase>tuple ID</foreignphrase>, ou
identifiant de ligne) de la ligne cible originale&nbsp;; cette donnée est
envoyée au nœud <literal>ModifyTable</literal>, qui utilise l'information
pour créer un nouveau nœud mis à jour et pour marquer l'ancienne ligne
comme supprimée. Pour <command>DELETE</command>, la seule colonne qui est
réellement renvoyée par le plan est le TID, et le nœud
<literal>ModifyTable</literal> utilise simplement le TID pour visiter
chaque ligne cible et la marquer supprimée.
</para>

<para>
Une simple commande <command>INSERT ... VALUES</command> crée un arbre de
plan trivial consistant en un seul nœud <literal>Result</literal>, qui
calcule seulement une ligne résultat, en l'envoyant à
<literal>ModifyTable</literal> pour réaliser l'insertion.
</para>

</sect1>
Expand Down
14 changes: 8 additions & 6 deletions postgresql/backup.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1529,12 +1529,14 @@ SELECT pg_start_backup('label', true);
</para>

<para>
Par défaut, la récupération s'effectue sur la timeline en vigueur au
cours de la sauvegarde. Si l'on souhaite effectuer la récupération
dans une timeline fille (c'est-à-dire retourner à un état enregistré
après une tentative de récupération), il faut préciser l'identifiant de la timeline
dans <xref linkend="guc-recovery-target-timeline"/>. Il n'est pas possible de
récupérer dans des timelines antérieures à la sauvegarde.
Par défaut, la récupération s'effectue jusqu'à la dernière timeline
trouvée dans l'archive. Si vous souhaitez effectuer la récupération
uniquement pour la timeline de la sauvegarde ou jusqu'à une timeline
précise (c'est-à-dire retourner à un état enregistré après une
tentative de récupération), il faut préciser
<literal>current</literal> ou l'identifiant de la timeline cible dans
<xref linkend="guc-recovery-target-timeline"/>. Il n'est pas possible
de récupérer dans des timelines antérieures à la sauvegarde.
</para>
</sect2>

Expand Down
19 changes: 17 additions & 2 deletions postgresql/catalogs.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -6081,9 +6081,13 @@ SCRAM-SHA-256$<replaceable>&lt;nombre d'itération&gt;</replaceable>:<replaceabl
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>protrftypes</structfield> <type>oid[]</type>
(référence <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
L'OID du type de données pour lequel les transformations s'appliquent.
Un tableau de types de données argument/résultat pour lesquels
appliquer les transformations (à partir de la clause
<literal>TRANSFORM</literal> de la fonction). NULL sinon.
</para></entry>
</row>

Expand Down Expand Up @@ -7002,10 +7006,21 @@ SCRAM-SHA-256$<replaceable>&lt;nombre d'itération&gt;</replaceable>:<replaceabl
</para>
</listitem>
</varlistentry>

<varlistentry>
<term><symbol>SHARED_DEPENDENCY_TABLESPACE</symbol> (<literal>t</literal>)</term>
<listitem>
<para>
L'objet référencé (qui doit être un tablespace) est mentionné comme le
tablespace pour une relation qui n'a pas de stockage.
</para>
</listitem>
</varlistentry>
</variablelist>

D'autres types de dépendances peuvent s'avérer nécessaires dans le futur.
La définition actuelle ne supporte que les rôles comme objets référencés.
La définition actuelle ne supporte que les rôles et les tablespaces comme
objets référencés.
</para>

</sect1>
Expand Down Expand Up @@ -12526,7 +12541,7 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
</para>
<para>
Décalage à partir duquel l'allocation commence. NULL pour les
allocations anonymes et la mémoire inutilisée.
allocations anonymes car les détails relatifs sont inconnus.
</para></entry>
</row>
<row>
Expand Down
148 changes: 69 additions & 79 deletions postgresql/client-auth.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -186,13 +186,6 @@
d'une alerte dans les traces indiquant qu'il n'y a aucune connexion
correspondante.
</para>

<para>
Veuillez noter que les seules <link linkend="auth-methods">méthodes
d'authentification</link> supportées pour l'utilisation d'un
chiffrement <acronym>GSSAPI</acronym> sont <literal>gss</literal>,
<literal>reject</literal>, et <literal>trust</literal>.
</para>
</listitem>
</varlistentry>

Expand Down Expand Up @@ -1232,16 +1225,16 @@ omicron bryanh guest1

<para>
<productname>GSSAPI</productname> est un protocole du standard de
l'industrie pour l'authentification sécurisée définie dans RFC 2743.

l'industrie pour l'authentification sécurisée définie dans
<ulink url="https://tools.ietf.org/html/rfc2743">RFC 2743</ulink>.
<productname>PostgreSQL</productname>
supporte <productname>GSSAPI</productname> pour l'utilisation de soit une
couche d'authentification, chiffrée, soit uniquement une authentification.
supporte <productname>GSSAPI</productname> pour l'authentification,
le chiffrement des communications, ou les deux.
<productname>GSSAPI</productname> fournit une authentification automatique
(single sign-on) pour les systèmes qui le supportent. L'authentification
elle-même est sécurisée. Si le chiffrement <productname>GSSAPI</productname>
(voir <literal>hostgssenc</literal>) ou le chiffrement <acronym>SSL</acronym>
sont utilisés, les données envoyées au travers de la connexion à la base de
ou le chiffrement <acronym>SSL</acronym>
est utilisé, les données envoyées au travers de la connexion à la base de
données seront chiffrées, sinon elles ne le seront pas.
</para>

Expand All @@ -1253,42 +1246,49 @@ omicron bryanh guest1

<para>
Quand <productname>GSSAPI</productname> passe par
<productname>Kerberos</productname>, il utilise un service principal standard
au format
<productname>Kerberos</productname>, il utilise un principal service
standard au format
<literal><replaceable>nom_service</replaceable>/<replaceable>nom_hôte</replaceable>@<replaceable>domaine</replaceable></literal>.
Le serveur PostgreSQL acceptera n'importe quel service principal inclus dans le
fichier de clés utilisé par le serveur, mais il est nécessaire de faire attention de
spécifier les détails du bon service principal quand une connexion est effectuée
depuis le client utilisant le paramètre de connexion
<literal>krbsrvname</literal>. (Voir aussi <xref linkend="libpq-paramkeywords"/>.)
La valeur par défaut à l'installation, <literal>postgres</literal>,
peut être changée lors de la compilation en utilisant
<literal>./configure --with-krb-srvnam=</literal><replaceable>autrechose</replaceable>.
Dans la plupart des environnements, ce paramètre n'a jamais besoin d'être
changé. Quelques implémentations de Kerberos peuvent nécessiter un nom de
service différent, par exemple Microsoft Active Directory qui réclame que
le nom de service soit en majuscule (<literal>POSTGRES</literal>).
</para>
<para>
<replaceable>nom_hôte</replaceable> est le nom d'hôte pleinement qualifié
(<foreignphrase>fully qualified host name</foreignphrase>)
de la machine serveur. Le domaine du service principal est le domaine
préféré du serveur.
</para>

<para>
Les principals du client peuvent être mis en correspondance avec
différents noms d'utilisateurs <productname>PostgreSQL</productname> grâce
au fichier de configuration <filename>pg_ident.conf</filename>. Par
Le nom utilisé pour le principal sur une installation particulière n'est
pas encodé dans le serveur <productname>PostgreSQL</productname>&nbsp;; il
est en fait indiqué dans le fichier <firstterm>keytab</firstterm> que le
serveur lit pour déterminer son identité. Si plusieurs principaux sont
listés dans le fichier keytab, le serveur acceptera n'importe lequel parmi
eux. Le nom de royaume du serveur est le royaume préféré indiqué dans le
fichier de configuration Kerberos accessible au serveur.
</para>

<para>
Lors de la connexion, le client doit connaître le nom du principal du
serveur où il souhaite se connecter. La partie
<replaceable>servicename</replaceable> est habituellement
<literal>postgres</literal>, mais une autre valeur peut être sélectionnée
via le paramètre de connexion <xref linkend="libpq-connect-krbsrvname"/> de
<application>libpq</application>. La partie
<replaceable>hostname</replaceable> est le nom d'hôte complètement qualifié
auquel <application>libpq</application> se connecte. Le nom de royaume est
le royaume préféré indiqué dans le fichier de configuration Kerberos
accessible au client.
</para>

<para>
Le client aura aussi un nom de principal pour sa propre identité (et il
doit avoir un ticket valide pour ce principal). Pour utiliser
<productname>GSSAPI</productname> pour l'authentification, le principal du
client doit être associé avec un nom d'utilisateur de base
<productname>PostgreSQL</productname>. Le fichier de configuration
<filename>pg_ident.conf</filename> peut être utilisé pour établir une
correspondance entre les principaux et les noms d'utilisateurs. Par
exemple, <literal>pgusername@realm</literal> pourrait correspondre à
<literal>pgusername</literal>. De la même façon, vous pouvez utiliser le
principal complet <literal>username@realm</literal> comme nom de rôle dans
<productname>PostgreSQL</productname> sans aucune correspondance.
</para>

<para>
<productname>PostgreSQL</productname> supporte aussi un paramètre pour
supprimer le royaume du principal. Cette méthode est supportée pour des
<productname>PostgreSQL</productname> supporte aussi la correspondance
entre principaux de clients et noms d'utilisateur en supprimant le royaume
du principal. Cette méthode est supportée pour des
raisons de compatibilité ascendante et est fortement déconseillé car il
est ensuite impossible de distinguer différents utilisateurs avec le même
nom d'utilisateur mais un domaine différent. Pour l'activer, configurez
Expand All @@ -1302,49 +1302,30 @@ omicron bryanh guest1
</para>

<para>
Le fichier de clés du serveur doit être lisible (et de préférence
uniquement lisible, donc sans écriture possible) par le compte serveur
<productname>PostgreSQL</productname> (voir aussi la
<xref linkend="postgres-user"/>). L'emplacement du fichier de clés est
indiqué grâce au paramètre de configuration
<xref linkend="guc-krb-server-keyfile"/>. La valeur par défaut est
<filename>/usr/local/pgsql/etc/krb5.keytab</filename> (ou tout autre
répertoire indiqué comme <varname>sysconfdir</varname> lors de la
compilation). Pour des raisons de sécurité, il est recommandé d'utiliser un
fichier de clés séparé pour <productname>PostgreSQL</productname>
uniquement plutôt que d'ouvrir les droits sur le fichier de clés du
système.
L'emplacement du fichier keytab du serveur est indiqué grâce au paramètre
de configuration <xref linkend="guc-krb-server-keyfile"/>. Pour des raisons
de sécurité, il est recommandé d'utiliser un fichier de clés séparé pour
<productname>PostgreSQL</productname> uniquement plutôt que d'autoriser le
serveur à lire le fichier keytab du système. Assurez-vous que le fichier
keytab du serveur est lisible (et de préférence seulement lisible, pas
modifiable) par le compte serveur <productname>PostgreSQL</productname>
(voir aussi <xref linkend="postgres-user"/>).
</para>

<para>
Le fichier de clés est généré pour le logiciel Kerberos&nbsp;; voir la
documentation de Kerberos pour plus de détails. L'exemple suivant est
valable pour des implémentations de Kerberos 5 compatible MIT&nbsp;:
Le fichier de clés est généré en utilisant le logiciel Kerberos&nbsp;; voir
la documentation de Kerberos pour plus de détails. L'exemple suivant montre
comment le faire en utilisant l'outil <application>kadmin</application> des
implémentations compatibles MIT de Kerberos 5&nbsp;:
<screen>
<prompt>kadmin% </prompt><userinput>ank -randkey postgres/server.my.domain.org</userinput>
<prompt>kadmin% </prompt><userinput>addprinc -randkey postgres/server.my.domain.org</userinput>
<prompt>kadmin% </prompt><userinput>ktadd -k krb5.keytab postgres/server.my.domain.org</userinput>
</screen>
</para>

<para>
Lors de la connexion à la base de données, il faut s'assurer de posséder
un ticket pour le service principal correspondant au nom d'utilisateur de base
de données souhaité. Par exemple, pour le nom d'utilisateur PostgreSQL
<literal>fred</literal>, le service principal <literal>fred@EXAMPLE.COM</literal>
pourrait se connecter. Pour autoriser aussi le service principal
<literal>fred/users.example.com@EXAMPLE.COM</literal>, il faut utiliser une
correspondance de nom d'utilisateur, comme décrit dans <xref
linkend="auth-username-maps"/>.
</para>

<para>
Le support de GSSAPI doit être activé lors de la construction de
<productname>PostgreSQL</productname>&nbsp;; voir
<xref linkend="installation"/> pour plus d'informations.
</para>

<para>
Les options de configuration suivantes sont supportées pour
<productname>GSSAPI</productname>&nbsp;:
Les options d'authentification suivantes sont supportées pour
la méthode d'authentification <productname>GSSAPI</productname>&nbsp;:
<variablelist>
<varlistentry>
<term><literal>include_realm</literal></term>
Expand Down Expand Up @@ -1411,9 +1392,9 @@ omicron bryanh guest1
<term><literal>map</literal></term>
<listitem>
<para>
Permet la mise en correspondance entre les noms système et base de
données. Voir <xref linkend="auth-username-maps"/> pour plus de détails.
Pour un principal GSSAPI/Kerberos, tel que
Permet la mise en correspondance entre les principaux clients et les
noms d'utilisateurs de base. Voir <xref linkend="auth-username-maps"/>
pour plus de détails. Pour un principal GSSAPI/Kerberos, tel que
<literal>username@EXAMPLE.COM</literal> (ou, moins communément,
<literal>username/hostbased@EXAMPLE.COM</literal>), le nom d'utilisateur
utilisé pour la correspondance est
Expand Down Expand Up @@ -1442,6 +1423,15 @@ omicron bryanh guest1
</variablelist>
</para>

<para>
En plus de ces paramètres, qui peuvent être différents pour différentes
entrées <filename>pg_hba.conf</filename>, il existe le paramètre serveur de
configuration <xref linkend="guc-krb-caseins-users"/>. S'il est configuré à
true, les principaux clients sont comparés aux entrées de la carte
utilisateurs, sans attention à la casse. Si <literal>krb_realm</literal>
est configuré, il est aussi comparé sans attention à la casse.
</para>

</sect1>

<sect1 id="sspi-auth">
Expand Down

0 comments on commit c955306

Please sign in to comment.