Skip to content

Commit

Permalink
Merge v14 beta 1
Browse files Browse the repository at this point in the history
  • Loading branch information
@gleu
gleu committed Jun 7, 2021
1 parent 91acb98 commit c51772a
Show file tree
Hide file tree
Showing 223 changed files with 17,286 additions and 11,728 deletions.
2 changes: 1 addition & 1 deletion postgresql/Makefile
View file
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ html:
NO_GENERATED_HEADERS=yes
NO_TEMP_INSTALL=yes

VERSION = 13
VERSION = 14

all: html man

Expand Down
214 changes: 206 additions & 8 deletions postgresql/amcheck.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -8,12 +8,12 @@

<para>
Le module <filename>amcheck</filename> fournit des fonctions vous permettant
de vérifier la cohérence logique de la structure des relations. Si la
structure semble valide, aucune erreur n'est levée.
de vérifier la cohérence logique de la structure des relations.
</para>

<para>
Les fonctions vérifient diverses <emphasis>propriétés invariantes</emphasis>
Les fonctions spécifiques aux B-Tree vérifient diverses <emphasis>propriétés
invariantes</emphasis>
dans la structure de la représentation de certains relations. La justesse
des fonctions permettant l'accès aux données durant les parcours d'index et
d'autres opérations importantes reposent sur le fait que ces propriétés
Expand All @@ -25,7 +25,8 @@
raison ou une autre, cette propriété invariante spécifique n'est plus
vérifiée, il faut s'attendre à ce que des recherches binaires sur la page
affectée renseignent de manière erronée les parcours d'index, avec pour
conséquence des résultats de requêtes SQL erronés.
conséquence des résultats de requêtes SQL erronés. Si la structure semble
valide, aucune erreur n'est levée.
</para>

<para>
Expand All @@ -39,8 +40,23 @@
</para>

<para>
Les fonctions du module <filename>amcheck</filename> ne peuvent être
exécutées que par des super utilisateurs.
Unlike the B-Tree checking functions which report corruption by raising
errors, the heap checking function <function>verify_heapam</function> checks
a table and attempts to return a set of rows, one row per corruption
detected. Despite this, if facilities that
<function>verify_heapam</function> relies upon are themselves corrupted, the
function may be unable to continue and may instead raise an error.
</para>

<para>
Permission to execute <filename>amcheck</filename> functions may be granted
to non-superusers, but before granting such permissions careful consideration
should be given to data security and privacy concerns. Although the
corruption reports generated by these functions do not focus on the contents
of the corrupted data so much as on the structure of that data and the nature
of the corruptions found, an attacker who gains permission to execute these
functions, particularly if the attacker can also induce corruption, might be
able to infer something of the data itself from such messages.
</para>

<sect2>
Expand Down Expand Up @@ -202,14 +218,158 @@ SET client_min_messages = DEBUG1;
progression avec un niveau de détail raisonnable.
</para>
</tip>

<variablelist>
<varlistentry>
<term>
<function>
verify_heapam(relation regclass,
on_error_stop boolean,
check_toast boolean,
skip text,
startblock bigint,
endblock bigint,
blkno OUT bigint,
offnum OUT integer,
attnum OUT integer,
msg OUT text)
returns setof record
</function>
</term>
<listitem>
<para>
Checks a table for structural corruption, where pages in the relation
contain data that is invalidly formatted, and for logical corruption,
where pages are structurally valid but inconsistent with the rest of the
database cluster.
</para>
<para>
The following optional arguments are recognized:
</para>
<variablelist>
<varlistentry>
<term><literal>on_error_stop</literal></term>
<listitem>
<para>
If true, corruption checking stops at the end of the first block in
which any corruptions are found.
</para>
<para>
Defaults to false.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>check_toast</literal></term>
<listitem>
<para>
If true, toasted values are checked against the target relation's
TOAST table.
</para>
<para>
This option is known to be slow. Also, if the toast table or its
index is corrupt, checking it against toast values could conceivably
crash the server, although in many cases this would just produce an
error.
</para>
<para>
Defaults to false.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>skip</literal></term>
<listitem>
<para>
If not <literal>none</literal>, corruption checking skips blocks that
are marked as all-visible or all-frozen, as specified.
Valid options are <literal>all-visible</literal>,
<literal>all-frozen</literal> and <literal>none</literal>.
</para>
<para>
Defaults to <literal>none</literal>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>startblock</literal></term>
<listitem>
<para>
If specified, corruption checking begins at the specified block,
skipping all previous blocks. It is an error to specify a
<literal>startblock</literal> outside the range of blocks in the
target table.
</para>
<para>
By default, checking begins at the first block.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>endblock</literal></term>
<listitem>
<para>
If specified, corruption checking ends at the specified block,
skipping all remaining blocks. It is an error to specify an
<literal>endblock</literal> outside the range of blocks in the target
table.
</para>
<para>
By default, all blocks are checked.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
For each corruption detected, <function>verify_heapam</function> returns
a row with the following columns:
</para>
<variablelist>
<varlistentry>
<term><literal>blkno</literal></term>
<listitem>
<para>
The number of the block containing the corrupt page.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>offnum</literal></term>
<listitem>
<para>
The OffsetNumber of the corrupt tuple.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>attnum</literal></term>
<listitem>
<para>
The attribute number of the corrupt column in the tuple, if the
corruption is specific to a column and not the tuple as a whole.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>msg</literal></term>
<listitem>
<para>
A message describing the problem detected.
</para>
</listitem>
</varlistentry>
</variablelist>
</listitem>
</varlistentry>
</variablelist>
</sect2>

<sect2>
<title>Vérification optionnelle <parameter>heapallindexed</parameter></title>

<para>
Quand l'argument <parameter>heapallindexed</parameter> des fonctions de
vérification est à <literal>true</literal>, une phase de vérification
vérification des B-Tree est à <literal>true</literal>, une phase de vérification
supplémentaire est opérée sur la table associée à l'index cible. Elle
consiste en une opération <command>CREATE INDEX</command>
<quote>bidon</quote> qui vérifie la présence de tous les nouveaux
Expand Down Expand Up @@ -253,7 +413,7 @@ SET client_min_messages = DEBUG1;
<para>
<filename>amcheck</filename> peut être efficace pour détecter différents
types de modes d'échec que les <link
linkend="app-initdb-data-checksums"><application>sommes de contrôle de page
linkend="app-initdb-data-checksums"><application>sommes de contrôle
</application></link> n'arriveront jamais à détecter. Cela inclut&nbsp;:

<itemizedlist>
Expand Down Expand Up @@ -369,7 +529,45 @@ SET client_min_messages = DEBUG1;
</para>
</listitem>
</itemizedlist>
</para>

<para>
Structural corruption can happen due to faulty storage hardware, or
relation files being overwritten or modified by unrelated software.
This kind of corruption can also be detected with
<link linkend="checksums"><application>data page
checksums</application></link>.
</para>

<para>
Relation pages which are correctly formatted, internally consistent, and
correct relative to their own internal checksums may still contain
logical corruption. As such, this kind of corruption cannot be detected
with <application>checksums</application>. Examples include toasted
values in the main table which lack a corresponding entry in the toast
table, and tuples in the main table with a Transaction ID that is older
than the oldest valid Transaction ID in the database or cluster.
</para>

<para>
Multiple causes of logical corruption have been observed in production
systems, including bugs in the <productname>PostgreSQL</productname>
server software, faulty and ill-conceived backup and restore tools, and
user error.
</para>

<para>
Corrupt relations are most concerning in live production environments,
precisely the same environments where high risk activities are least
welcome. For this reason, <function>verify_heapam</function> has been
designed to diagnose corruption without undue risk. It cannot guard
against all causes of backend crashes, as even executing the calling
query could be unsafe on a badly corrupted system. Access to <link
linkend="catalogs-overview">catalog tables</link> is performed and could
be problematic if the catalogs themselves are corrupted.
</para>

<para>
De manière générale, <filename>amcheck</filename> ne peut que prouver la
présence d'une corruption&nbsp;; il ne peut pas en prouver l'absence.
</para>
Expand Down
23 changes: 23 additions & 0 deletions postgresql/appendix-obsolete-default-roles.xml
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
<?xml version="1.0" encoding="UTF-8"?>
<!-- doc/src/sgml/obsolete-default-roles.sgml -->
<!--
See doc/src/sgml/obsolete.sgml for why this file exists. Do not change the id attribute.
-->

<sect1 id="default-roles" xreflabel="default-roles">
<title>Default Roles renamed to Predefined Roles</title>

<indexterm>
<primary>default-roles</primary>
</indexterm>

<para>
PostgreSQL 13 and below used the term 'Default Roles', however, as these
roles are not able to actually be changed and are installed as part of the
system at initialization time, the more appropriate term to use is "Predefined Roles".
See <xref linkend="predefined-roles"/> for current documentation regarding
Predefined Roles, and <link linkend="release-prior">the release notes for
PostgreSQL 14</link> for details on this change.
</para>

</sect1>
1 change: 1 addition & 0 deletions postgresql/appendix-obsolete.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -34,6 +34,7 @@
-->

&obsolete-recovery-config;
&obsolete-default-roles;
&obsolete-pgxlogdump;
&obsolete-pgresetxlog;
&obsolete-pgreceivexlog;
Expand Down
53 changes: 28 additions & 25 deletions postgresql/arch-dev.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -17,8 +17,7 @@
Ce chapitre présente la structure interne du serveur
<productname>PostgreSQL</productname>.
La lecture des sections qui suivent permet de se faire une idée de la
façon dont une requête est exécutée&nbsp;; les opérations
internes ne sont pas décrites dans le détail.
façon dont une requête est exécutée.
Ce chapitre a, au contraire, pour but d'aider le lecteur à
comprendre la suite des opérations effectuées sur le serveur depuis la
réception d'une requête jusqu'au retour des résultats.
Expand Down Expand Up @@ -110,21 +109,25 @@
<title>Établissement des connexions</title>

<para>
<productname>PostgreSQL</productname> est écrit suivant un simple modèle
client/serveur <quote>processus par utilisateur</quote>. Dans ce
modèle, il existe un <firstterm>processus client</firstterm> connecté à un
seul <firstterm>processus serveur</firstterm>. Comme le nombre de
connexions établies n'est pas connu à l'avance, il est nécessaire
d'utiliser un <firstterm>processus maître</firstterm> qui lance un
processus serveur à chaque fois qu'une connexion est demandée. Ce
processus maître s'appelle <literal>postgres</literal> et écoute les
connexions entrantes sur le port TCP/IP indiqué.
À chaque fois qu'une demande de connexion est
détectée, le processus <literal>postgres</literal> lance un nouveau
processus serveur. Les tâches du serveur communiquent entre elles en
utilisant des <firstterm>sémaphores</firstterm> et de la <firstterm>mémoire
partagée</firstterm> pour s'assurer de l'intégrité des données lors d'accès
simultanés aux données.
<productname>PostgreSQL</productname> implements a
<quote>process per user</quote> client/server model.
In this model, every
<glossterm linkend="glossary-client">client process</glossterm>
connects to exactly one
<glossterm linkend="glossary-backend">backend process</glossterm>.
As we do not know ahead of time how many connections will be made,
we have to use a <quote>supervisor process</quote> that spawns a new
backend process every time a connection is requested. This supervisor
process is called
<glossterm linkend="glossary-postmaster">postmaster</glossterm>
and listens at a specified TCP/IP port for incoming connections.
Whenever it detects a request for a connection, it spawns a new
backend process. Those backend processes communicate with each
other and with other processes of the
<glossterm linkend="glossary-instance">instance</glossterm>
using <firstterm>semaphores</firstterm> and
<glossterm linkend="glossary-shared-memory">shared memory</glossterm>
to ensure data integrity throughout concurrent data access.
</para>

<para>
Expand All @@ -137,12 +140,12 @@
</para>

<para>
Une fois la connexion établie, le processus client peut envoyer une requête
au serveur (<firstterm>backend</firstterm>). La requête est transmise en
texte simple, c'est-à-dire qu'aucune analyse n'a besoin d'être réalisée au
niveau de l'<firstterm>interface</firstterm> (client). Le serveur analyse
la requête, crée un <firstterm>plan d'exécution</firstterm>, exécute le
plan et renvoie les lignes trouvées au client par la connexion établie.
Once a connection is established, the client process can send a query
to the backend process it's connected to. The query is transmitted using
plain text, i.e., there is no parsing done in the client. The backend
process parses the query, creates an <firstterm>execution plan</firstterm>,
executes the plan, and returns the retrieved rows to the client
by transmitting them over the established connection.
</para>
</sect1>

Expand Down Expand Up @@ -223,7 +226,7 @@
<para>
La description détaillée de <application>bison</application> ou des règles
de grammaire données dans <filename>gram.y</filename> dépasse le cadre
de ce document. Il existe de nombreux livres et documentations en
de ce manuel. Il existe de nombreux livres et documentations en
relation avec <application>flex</application> et
<application>bison</application>. Il est préférable d'être familier avec
<application>bison</application> avant de commencer à étudier la grammaire
Expand Down Expand Up @@ -416,7 +419,7 @@
est triée selon les attributs de la
jointure avant que la jointure ne commence. Puis, les deux relations
sont parcourues en parallèle et les lignes correspondantes sont
combinées pour former des lignes jointes. Ce type de jointure est plus
combinées pour former des lignes jointes. Ce type de jointure est
intéressant parce que chaque relation n'est parcourue qu'une seule fois.
Le tri requis peut être réalisé soit par une étape explicite de tri
soit en parcourant la relation dans le bon ordre en utilisant un index
Expand Down

0 comments on commit c51772a

Please sign in to comment.