Mise à jour en version 15.2

gleu · Feb 22, 2023 · f6cca93 · f6cca93
1 parent cc67f15
commit f6cca93
Show file tree

Hide file tree

Showing 21 changed files with 1,511 additions and 266 deletions.
diff --git a/postgresql/config.xml b/postgresql/config.xml
@@ -811,7 +811,7 @@ include 'nom_fichier'
 
     <para>
      Une valeur commençant par <literal>@</literal> indique qu'un socket abstrait
-     doit être créé (actuellement supporté sous Linux et Windows).
+     doit être créé (actuellement uniquement supporté sous Linux).
      Dans ce cas, la valeur ne doit pas spécifier un <quote>répertoire</quote>
      mais un préfixe à partir duquel le nom du socket est construit de la même
      manière que pour un socket de système de fichiers. Alors que le préfixe d'un
@@ -11448,7 +11448,7 @@ SET XML OPTION { DOCUMENT | CONTENT };
      </listitem>
     </varlistentry>
 
-    <varlistentry>
+    <varlistentry id="guc-trace-locks" xreflabel="trace_locks">
      <term><varname>trace_locks</varname> (<type>boolean</type>)</term>
      <listitem>
       <indexterm>
@@ -11490,7 +11490,7 @@ LOG:  CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
      </listitem>
     </varlistentry>
 
-    <varlistentry>
+    <varlistentry id="guc-trace-lwlocks" xreflabel="trace_lwlocks">
      <term><varname>trace_lwlocks</varname> (<type>boolean</type>)</term>
      <listitem>
       <indexterm>
@@ -11510,7 +11510,7 @@ LOG:  CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
      </listitem>
     </varlistentry>
 
-    <varlistentry>
+    <varlistentry id="guc-trace-userlocks" xreflabel="trace_userlocks">
      <term><varname>trace_userlocks</varname> (<type>boolean</type>)</term>
      <listitem>
       <indexterm>
@@ -11524,7 +11524,7 @@ LOG:  CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
      </listitem>
     </varlistentry>
 
-    <varlistentry>
+    <varlistentry id="guc-trace-lock-oidmin" xreflabel="trace_lock_oidmin">
      <term><varname>trace_lock_oidmin</varname> (<type>integer</type>)</term>
      <listitem>
       <indexterm>
@@ -11543,7 +11543,7 @@ LOG:  CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
      </listitem>
     </varlistentry>
 
-    <varlistentry>
+    <varlistentry id="guc-trace-lock-table" xreflabel="trace_lock_table">
      <term><varname>trace_lock_table</varname> (<type>integer</type>)</term>
      <listitem>
       <indexterm>
@@ -11578,7 +11578,7 @@ LOG:  CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
      </listitem>
     </varlistentry>
 
-    <varlistentry>
+    <varlistentry id="guc-debug-deadlocks" xreflabel="debug_deadlocks">
      <term><varname>log_btree_build_stats</varname> (<type>boolean</type>)</term>
      <listitem>
       <indexterm>
@@ -11596,7 +11596,7 @@ LOG:  CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
      </listitem>
     </varlistentry>
 
-    <varlistentry id="guc-wal-consistency-checking" xreflabel="wal_consistency_checking">
+    <varlistentry id="guc-log-btree-build-stats" xreflabel="log_btree_build_stats">
      <term><varname>wal_consistency_checking</varname> (<type>string</type>)
       <indexterm>
        <primary>Paramètre de configuration <varname>wal_consistency_checking</varname></primary>

diff --git a/postgresql/ddl.xml b/postgresql/ddl.xml
@@ -3348,27 +3348,29 @@ COMMIT;</programlisting>
      <listitem>
       <para>
        Contraindre les utilisateurs à de schémas privés. Pour implémenter cela,
-       exécutez tout d'abord <literal>REVOKE CREATE ON SCHEMA public FROM
-       PUBLIC</literal>. Puis, pour chaque utilisateur ayant besoin de créer des
-       objets permanents, créez un schéma du même nom que l'utilisateur.
-       Rappelez-vous que le chemin de recherche des schémas commence avec
-       <literal>$user</literal>, qui est résolu avec le nom de l'utilisateur.
-       De ce fait, si chaque utilisateur a un schéma privé, ils accèdent par
-       défaut à leur propre schéma. Une fois que ce système a été adopté dans
-       une base de données où des utilisateurs sans confiance sont déjà
-       connectés, pensez à regarder dans le schéma public pour des objets nommés
-       comme des objets du schéma <literal>pg_catalog</literal>. Ceci permet
-       d'avoir une utilisation sécurisée des schémas, sauf si un utilisateur
-       sans confiance est le propriétaire de la base ou détient le droit
-       <literal>CREATEROLE</literal>, auquel cas aucune utilisation sécurisée
-       des schémas n'existe.
+       assurez-vous tout d'abord que les schémas n'ont pas le droit
+       <literal>CREATE</literal> pour public. Ensuite, pour chaque utilisateur
+       devant créer des objets permanents, créez un schéma de même nom que
+       l'utilisateur, par exemple <literal>CREATE SCHEMA alice AUTHORIZATION
+       alice</literal>. (Rappelez-vous que le chemin de recherche par défaut
+       commence avec <literal>$user</literal>, ce qui est remplacé par le nom de
+       l'utilisateur. De ce fait, si chaque utilisateur a un schéma séparé, ils
+       accèdent à leur schéma par défaut.) Cette méthode est une méthode
+       d'utilisation de schéma sécurisé sauf si un utilisateur malin est le
+       propriétaire de la base de données ou dispose de l'attribut
+       <literal>CREATEROLE</literal>, auquel cas aucune méthode d'utilisation
+       sécurisée des schémas n'existe.
       </para>
       <para>
-       Si la base est issue d'une mise à jour d'une version 14 ou antérieure de
-       <productname>PostgreSQL</productname>, le <literal>REVOKE</literal> est
-       essentiel. Sinon la configuration par défaut suit cette méthode&nbsp;;
-       les utilisateurs standards peuvent seulement créer des objets temporaires
-       jusqu'à ce qu'un utilisateur privilégié fournisse un schéma.
+       Avec <productname>PostgreSQL</productname> 15 et les versions suivantes,
+       la configuration par défaut accepte cette méthode d'utilisation. Dans les
+       versions précédentes, ou lors de l'utilisation d'une base de donnée mise
+       à jour d'une version précédente, vous aurez besoin de supprimer
+       l'attribut <literal>CREATE</literal> sur public à partir du schéma
+       <literal>public</literal> (lancez <literal>REVOKE CREATE ON SCHEMA public
+       FROM PUBLIC</literal>). Puis considérez la réalisation d'un audit du
+       schéma <literal>public</literal> pour des objets nommés comme les objets
+       du schéma <literal>pg_catalog</literal>.
       </para>
      </listitem>
 

diff --git a/postgresql/event-trigger.xml b/postgresql/event-trigger.xml
@@ -1207,9 +1207,9 @@ noddl(PG_FUNCTION_ARGS)
 
     trigdata = (EventTriggerData *) fcinfo->context;
 
-    ereport(ERROR,
-        (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
-                 errmsg("command \"%s\" denied", trigdata->tag)));
+    (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
+     errmsg("command \"%s\" denied",
+            GetCommandTagName(trigdata->tag))));
 
     PG_RETURN_NULL();
 }

diff --git a/postgresql/func.xml b/postgresql/func.xml
@@ -1612,6 +1612,10 @@ repeat('Pg', 4) <returnvalue>PgPgPgPg</returnvalue>
       <para>
        <literal>round(42.4382, 2)</literal>
        <returnvalue>42.44</returnvalue>
+       </para>
+       <para>
+        <literal>round(1234.56, -1)</literal>
+        <returnvalue>1230</returnvalue>
       </para></entry>
     </row>
 

diff --git a/postgresql/legal.xml b/postgresql/legal.xml
@@ -1,16 +1,16 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<date>2022</date>
+<date>2023</date>
 
 <copyright>
- <year>1996&ndash;2022</year>
+ <year>1996&ndash;2023</year>
  <holder>The PostgreSQL Global Development Group</holder>
 </copyright>
 
 <legalnotice id="legalnotice">
  <title>Legal Notice</title>
 
  <para>
-  <productname>PostgreSQL</productname> is Copyright &copy; 1996&ndash;2022
+  <productname>PostgreSQL</productname> is Copyright &copy; 1996&ndash;2023
   by the PostgreSQL Global Development Group.
  </para>
 

diff --git a/postgresql/libpq.xml b/postgresql/libpq.xml
@@ -5041,10 +5041,11 @@ char *PQresultVerboseErrorMessage(const PGresult *res,
   </para>
 
   <para>
-   Alors que l'API de pipeline a été introduite dans
+   Alors que l'API de pipeline de <application>libpq</application> a été introduite dans
    <productname>PostgreSQL</productname> 14, c'est une fonctionnalité du côté
    client qui ne requiert pas de support spécial côté serveur, et fonctionne
-   avec tout serveur qui supporte le protocole de requêtes étendu v3.
+   avec tout serveur qui supporte le protocole de requêtes étendu v3. Pour
+   plus d'informations, voir <xref linkend="protocol-flow-pipelining"/>.
   </para>
 
   <sect2 id="libpq-pipeline-using">

diff --git a/postgresql/logical-replication.xml b/postgresql/logical-replication.xml
@@ -1222,26 +1222,29 @@ test_sub=# SELECT * FROM child ORDER BY a;
    synchronisation initiale des données, ignorant en cela les liste de colonnes.
   </para>
 
-  <sect2 id="logical-replication-col-list-combining">
-   <title>Combiner plusieurs listes de colonnes</title>
-
-   <warning>
-    <para>
-     Avoir une souscription comprenant plusieurs publications où la même table a
-     été publiée avec différentes listes de colonnes n'est pas supporté. Ceci
-     signifie que changer les listes de colonnes des tables en cours
-     d'abonnement peut causer une incohérence des listes de colonnes parmi les
-     publications, auquel cas <xref linkend="sql-alterpublication"/> réussira
-     mais, plus tard, le walsender sur le publieur ou l'abonné pourrait renvoyer
-     une erreur. Dans ce scénario, l'utilisateur a besoin de re-créer
-     l'abonnement après l'ajustement de la liste de colonnes ou la suppression
-     de la publication problématique en utilisant <literal>ALTER SUBSCRIPTION
-     ... DROP PUBLICATION</literal>, puis l'ajouter après avoir ajuster la liste
-     de colonnes.
-    </para>
-   </warning>
-
-  </sect2>
+  <warning id="logical-replication-col-list-combining">
+   <title>Attention&nbsp;: Combiner des listes de plusieurs publications</title>
+   <para>
+    Actuellement, il n'est pas possible qu'une souscription soit entreprise
+    auprès de plusieurs publications quand la même table a été publiée avec des
+    listes de colonnes différentes. <xref linkend="sql-createsubscription"/>
+    interdit la création de telles souscriptions mais il est toujours possible
+    d'arriver dans cette situation par l'ajout ou la modification de listes de
+    colonnes du côté publication une fois que la souscription a été créée.
+   </para>
+   <para>
+    Ceci signifie que la modification de liste de colonnes sur les publications
+    déjà souscrites peut amener à des erreurs du côté souscripteur.
+   </para>
+   <para>
+    Si ce problème affecte une souscription, la seule façon de reprendre la
+    réplication est d'ajuster une des listes de colonnes côté publication pour
+    que les listes correspondent&nbsp;; puis soit de créer de nouveau la
+    souscription, soit utiliser <literal>ALTER SUBSCRIPTION ... DROP
+    PUBLICATION</literal> pour supprimer une des publications problématiques et
+    l'ajouter de nouveau après.
+   </para>
+  </warning>
 
   <sect2 id="logical-replication-col-list-examples">
    <title>Exemples</title>