Nouveautés de PostgreSQL 12

Les nouveautés

Développement SQL
Partitionnement
Réplication
Monitoring
Administration
Performances : index
Incompatibilités
Fonctionnalités futures
Ateliers

Développement / SQL

Colonnes générées
Colonne OIDS
COMMIT / ROLLBACK AND CHAIN
COPY FROM WHERE

Ajout du support des colonnes générées

Colonnes générées par une expression
- évaluation à l’écriture (stored)
- plus efficace qu’un trigger
- colonne en lecture seule (sauf default)
- évaluation à la lecture prochainement (virtual)
- colonnes indexables

Cette fonctionnalité du standard SQL, permet de créer des colonnes calculées à partir d’une expression plutôt qu’une assignation classique.

L’expression est évaluée à l’écriture (stored) et le résultat est inséré dans la colonne.

L’évaluation à la lecture (virtual) n’est pas encore implémentée mais est prévue dans une prochaine version.

-- définition de la table

$ CREATE TABLE table1(
    id serial PRIMARY KEY,
    a int NOT NULL DEFAULT 0,
    b int NOT NULL DEFAULT 0,
    prod int generated always as (a * b) stored
) ;

$ \d table1
Table "public.table1"
Column |  Type   | Collation | Nullable |              Default               
--------+---------+-----------+----------+------------------------------------
id     | integer |           | not null | nextval('table1_id_seq'::regclass)
a      | integer |           | not null | 0
b      | integer |           | not null | 0
prod   | integer |           |          | generated always as (a * b) stored
Indexes:
"table1_pkey" PRIMARY KEY, btree (id)


-- insertion

INSERT INTO table1 (a,b) VALUES (6,7) ;
SELECT * FROM table1 ;

 id | a | b | prod 
----+---+---+------
  1 | 6 | 7 |   42
(1 row)

Les modification des colonnes calculées sont interdites :

$ UPDATE table1 SET prod = 43 ;
ERROR:  column "prod" can only be updated to DEFAULT
DETAIL:  Column "prod" is a generated column.

À moins de rétablir la valeur par défaut :

$ UPDATE table1 SET prod = DEFAULT ;

Toutes mises à jour d’enregistrement étant une insertion d’un nouvel enregistrement (voir le fonctionnement du MVCC), les colonnes générées sont donc recalculées quel que soit le champ modifié.

Les index sont parfaitement utilisables sur les colonnes générées.

Restriction

expression immutable

Visibilité de la colonne OID

La fin des OIDS
- anomalies de restauration possible

Le comportement spécial de la colonne cachée oid, a été supprimé. Cette colonne si elle existe, sera visible comme toutes les autres colonnes et il n’est plus possible de créer des tables ayant ce champ spécial.

La restauration de ce type de table peut poser problème :

En version 11

=$ CREATE TABLE table2 (nom text, f_group int, sous_group int) WITH OIDS;
=$ INSERT INTO table2 SELECT i,i,i,i FROM generate_series(1,1000) i;
=$ SELECT * FROM TABLE2 LIMIT 3;

 nom  | f_group | sous_group 
------+---------+------------
 1    |       1 |          1
 2    |       2 |          2
 3    |       3 |          3

=$ SELECT oid,* FROM TABLE2 LIMIT 3;

  oid  | nom | f_group | sous_group 
-------+-----+---------+------------
 29256 | 1   |       1 |          1
 29257 | 2   |       2 |          2
 29258 | 3   |       3 |          3

Transfert vers une instance en v12

/usr/lib/postgresql/11/bin/pg_dump -o -p 5433 -t table2 postgres | psql -U postgres

SET
SET
SET
SET
SET
 set_config 
------------
 
(1 row)

SET
SET
SET
SET
SET
ERROR:  tables declared WITH OIDS are not supported
CREATE TABLE
ALTER TABLE
ERROR:  syntax error at or near "WITH"
LINE 1: COPY public.table2 (nom, f_group, sous_group) WITH OIDS FROM...
                                                      ^
invalid command \.
ERROR:  syntax error at or near "29256"
LINE 1: 29256 1 1 1

La version 12 rejette l’option WITH OIDS de l’ordre COPY FROM et la copie des données échoue.

COMMIT AND CHAIN / ROLLBACK AND CHAIN

COMMIT AND CHAIN
ROLLBACK AND CHAIN

Une transaction peut désormais être initiée immédiatement à la suite d’une autre et avec les mêmes caractéristiques (voir SET TRANSACTION).

Ceci permet d’enchaîner des transactions particulières tant que cela est possible, à défaut de quoi l’ouverture de la suivante échoue.

$ SHOW TRANSACTION_ISOLATION
transaction_isolation 
-----------------------
 read committed
(1 row)

$ BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;
$ SELECT 1;
$ COMMIT AND CHAIN ;
$ SHOW TRANSACTION_ISOLATION;
 transaction_isolation 
-----------------------
 repeatable read
(1 row)
$ END;
COMMIT
$ SHOW TRANSACTION_ISOLATION;
 transaction_isolation 
-----------------------
 read committed
(1 row)

COPY FROM WHERE…

COPY FROM... WHERE...

Il est désormais possible d’ajouter une clause WHERE à la commande COPY FROM et donc de contrôler les lignes qui seront retournées.

Exemple de COPY FROM conditionnel

En reprenant la table1 prcédente :


$ COPY table1 TO '/tmp/table1';
$ CREATE TABLE table11 AS SELECT * FROM table1 LIMIT 0;
$ COPY table11 FROM '/tmp/table1' WHERE a between 367080 and 367085; 
ERROR:  missing data for column "prod"
CONTEXT:  COPY table11, line 1: "367041 367041  0"

La commande CREATE TABLE AS ne reprend pas la colonne générée, nous supprimons donc cette colonne :

$ ALTER TABLE table11 DROP COLUMN prod ;
$ COPY table11 FROM '/tmp/table1' WHERE a BETWEEN 367080 AND 367085;
COPY 6

L’insertion par COPY a bien sélectionné les enregistrements désirés :

$ TABLE table11 ;
   id   |   a    | b 
--------+--------+---
 367080 | 367080 | 0
 367081 | 367081 | 0
 367082 | 367082 | 0
 367083 | 367083 | 0
 367084 | 367084 | 0
 367085 | 367085 | 0
(6 rows)

Partitionnement

Clés étrangères
Fonctions d’information :
- pg_partition_root()
- pg_partition_ancestors()
- pg_partition_tree()
Commande \dP

Clés étrangères dans les tables partitionnées

Support des clés étrangères entre tables partitionnées

Il est désormais possible de mettre en place une clé étrangère dans une tables partitionnée vers une autre table partitionnée. La relation sera établie entre la table partitionnée et toutes les partitions de la table référencée.

$ \d mere 
Partitioned table "public.mere"
Column |  Type   | Collation | Nullable | Default 
--------+---------+-----------+----------+---------
i      | integer |           | not null | 
idlieu | integer |           |          | 
Partition key: RANGE (i)
Indexes:
"mere_pkey" PRIMARY KEY, btree (i)
Foreign-key constraints:
"mere_idlieu_fkey" FOREIGN KEY (idlieu) REFERENCES lieu(id)
Referenced by:
TABLE "pere" CONSTRAINT "pere_idmere_fkey" FOREIGN KEY (idmere) REFERENCES mere(i)
Number of partitions: 2 (Use \d+ to list them.)

$ CREATE TABLE public.fille_1_5 (
    i integer NOT NULL,
    idlieu integer
);
ALTER TABLE ONLY public.mere ATTACH PARTITION public.fille_1_5 FOR VALUES FROM (1) TO (5);

$ CREATE TABLE pere (
    i INT PRIMARY KEY, 
    idlieu INT REFERENCES lieu(id), 
    idmere INT REFERENCES mere(i)
  ) PARTITION BY RANGE (i);

$ \d pere
          Partitioned table "public.pere"
 Column |  Type   | Collation | Nullable | Default 
--------+---------+-----------+----------+---------
 i      | integer |           | not null | 
 idlieu | integer |           |          | 
 idmere | integer |           |          | 
Partition key: RANGE (i)
Indexes:
    "pere_pkey" PRIMARY KEY, btree (i)
Foreign-key constraints:
    "pere_idlieu_fkey" FOREIGN KEY (idlieu) REFERENCES lieu(id)
    "pere_idmere_fkey" FOREIGN KEY (idmere) REFERENCES mere(i)
Number of partitions: 0

$ \d fille_1_5 
Table "public.fille_1_5"
Column |  Type   | Collation | Nullable | Default 
--------+---------+-----------+----------+---------
i      | integer |           | not null | 
idlieu | integer |           |          | 
Partition of: mere FOR VALUES FROM (1) TO (5)
Indexes:
"fille_1_5_pkey" PRIMARY KEY, btree (i)
Foreign-key constraints:
TABLE "mere" CONSTRAINT "mere_idlieu_fkey" FOREIGN KEY (idlieu) REFERENCES lieu(id)
Referenced by:
TABLE "pere" CONSTRAINT "pere_idmere_fkey" FOREIGN KEY (idmere) REFERENCES mere(i)

Fonctions d’information sur le partitionnement

pg_partition_root(regclass)
pg_partition_ancestors(regclass)
pg_partition_tree(regclass)

Commande psql pour les tables partitionnées

Commande \dP[tin+] [PATTERN]

Le client psql est maintenant doté d’une commande rapide pour lister les tables partitionnées :

\dP+
List of partitioned relations
Schema |   Name    |  Owner   |       Type        | Table 
--------+-----------+----------+-------------------+-------
public | mere      | postgres | partitioned table | 
public | meteo     | postgres | partitioned table | 
public | pere      | postgres | partitioned table | 
public | mere_pkey | postgres | partitioned index | mere
public | pere_pkey | postgres | partitioned index | pere

Réplication

Nouveauté des postgresql.confet recovery.conf
2 fichiers trigger
Paramètres modifiables à chaud
Fonction pg_promote()
Copie de slot de réplication

Nouveauté de `postgresql.conf` et `recovery.conf`

recovery.conf disparaît
tous les paramètres dans postgresql.conf

En PostgreSQL 12 le fichier recovery.conf disparaît. Les paramètres de l’ancien fichier recovery.conf sont dans le fichier postgresql.conf.

Si le fichier recovery.conf est présent, PostgreSQL refuse de démarrer.

FATAL:  using recovery command file "recovery.conf" is not supported
LOG:  startup process (PID 22810) exited with exit code 1
LOG:  aborting startup due to startup process failure
LOG:  database system is shut down

Les paramètres de l’ancien recovery.conf se retrouvent dans le fichier postgresql.conf, dans 2 sections.

Section pour les paramètres concernant le mode de recovery.

#------------------------------------------------------------------------------
# WRITE-AHEAD LOG
#------------------------------------------------------------------------------

# - Archive Recovery -
# These are only used in recovery mode.

restore_command = '/opt/pgsql/12b2/bin/pg_standby /opt/pgsql/archives %f %p %r'         
                                # command to use to restore $
                                # placeholders: %p = path of file to restore
                                #               %f = file name only
                                # e.g. 'cp /mnt/server/archivedir/%f %p'
                                # (change requires restart)
archive_cleanup_command = '/opt/pgsql/12b2/bin/pg_archivecleanup -d /opt/pgsql/archives %r'     
                                # command to execute$

#recovery_end_command = ''      # command to execute at completion of recovery

# - Recovery Target -

# Set these only when performing a targeted recovery.

#recovery_target = ''           # 'immediate' to end recovery as soon as a
                                # consistent state is reached
                                # (change requires restart)
#recovery_target_name = ''      # the named restore point to which recovery will proceed
                                # (change requires restart)
#recovery_target_time = ''      # the time stamp up to which recovery will proceed
                                # (change requires restart)
#recovery_target_xid = ''       # the transaction ID up to which recovery will proceed
                                # (change requires restart)
#recovery_target_lsn = ''       # the WAL LSN up to which recovery will proceed
                                # (change requires restart)
#recovery_target_inclusive = on # Specifies whether to stop:
                                # just after the specified recovery target (on)
                                # just before the recovery target (off)
                                # (change requires restart)
#recovery_target_timeline = 'latest'    # 'current', 'latest', or timeline ID
                                        # (change requires restart)
#recovery_target_action = 'pause'       # 'pause', 'promote', 'shutdown'
                                        # (change requires restart)

Section pour les paramètres concernant la configuration des réplicats.

#------------------------------------------------------------------------------
# REPLICATION
#------------------------------------------------------------------------------

# - Standby Servers -
# These settings are ignored on a master server.

#primary_conninfo = ''                  # connection string to sending server
                                        # (change requires restart)
#primary_slot_name = ''                 # replication slot on sending server
                                        # (change requires restart)
#promote_trigger_file = ''              # file name whose presence ends recovery
#hot_standby = on                       # "off" disallows queries during recovery
                                        # (change requires restart)
#max_standby_archive_delay = 30s        # max delay before canceling queries
                                        # when reading WAL from archive;
                                        # -1 allows indefinite delay
#max_standby_streaming_delay = 30s      # max delay before canceling queries
                                        # when reading streaming WAL;
                                        # -1 allows indefinite delay
#wal_receiver_status_interval = 10s     # send replies at least this often
                                        # 0 disables
#hot_standby_feedback = off             # send info from standby to prevent
                                        # query conflicts
#wal_receiver_timeout = 60s             # time that receiver waits for
                                        # communication from master
                                        # in milliseconds; 0 disables
#wal_retrieve_retry_interval = 5s       # time to wait before retrying to
                                        # retrieve WAL after a failed attempt
#recovery_min_apply_delay = 0           # minimum delay for applying changes during recovery

Paramètres renommés ou supprimés :

standby_mode a été supprimé des paramètres et est remplacé par un fichier trigger sur disque.
trigger_file a été renommé en promote_trigger_file.

2 fichiers trigger

standby.signal
recovery.signal

Paramètres modifiables à chaud

archive_cleanup_command
recovery_end_command
recovery_min_apply_delay
promote_trigger_file

Fonction pg_promote()

pg_promote depuis psql

PostgreSQL 12 offre la possibilité de promouvoir une instance standby (hot_standby) à l’aide d’une fonction psql.

Rappel des 2 possibilités de promotion en version 11 :

commande système : pg_ctl promote
création du fichier “trigger” en commande shell, en ayant préalablement configuré le paramètre trigger_file dans le fichier recovery.conf.

Dans les 2 cas il faut avoir accès au système de fichier avec les droits postgres.

Le commit mentionné ci-dessus offre un troisième moyen de déclencher une promotion avec une fonction système SQL.

Énorme avantage : il n’est pas nécessaire de se connecter physiquement au serveur pour déclencher la promotion d’une standby. On notera que cela nécessite que le serveur soit en capacité d’accepter des connexions et donc accessible en lecture (hot_standby).

Par défaut, la fonction pg_promote() attend la fin de la promotion pour renvoyer le résultat à l’appelant, avec un timeout max de 60 secondes. La fonction pg_promote() accepte 2 paramètres optionnels :

wait (booléen) : permet de ne pas attendre le résultat de la promotion (true par défaut)
wait_seconds : permet de renvoyer le résultat après ce délais (par défaut : 60 secondes)

La fonction renvoie true, si la promotion s’est bien déroulé et false sinon.

Exemple d’utilisation :

-- Par défaut sans paramètres 
postgres=# SELECT pg_promote();
 pg_promote 
------------
 t
-- Attend au plus 10 secondes
postgres=# SELECT pg_promote(true,10);
-- Pas d'attente
postgres=# SELECT pg_promote(false);

L’accès à la fonction pg_promote() est limité aux super-utilisateurs. A noter qu’il est possible de déléguer les droits à un autre utilisateur ou un autre rôle :

postgres=# GRANT EXECUTE ON FUNCTION pg_promote TO mon_role;
GRANT

La fonction exécutée sur une instance non standby renvoie une erreur.

postgres=# select pg_promote(true,10);
psql: ERROR:  recovery is not in progress
HINT:  Recovery control functions can only be executed during recovery.

Copie de slot de réplication

pg_copy_physical_replication_slot('slot1','slot2')

Rappel historique des slots de réplication :

Introduction du slot de réplication physique en version 9.4 pour éviter la suppression des WAL sur l’instance primaire alors qu’un réplicat est arrêté ou trop en retard sur sa réplication.
Le slot de réplication logique a été introduit en version PostgreSQL 10.
PostgreSQL 12 permet grâce à 2 fonctions de copier les slots de réplications.

Cas d’usage de ces fonctions :

Attacher 2 réplicats à la même instance principale en utilisant 2 slots de réplication physique différents. Les réplicats sont réalisés à partir du même backup, pour gagner du temps et de la place, et commencent par le même LSN.

L’utilitaire pg_basebackup est utilisé pour créer la sauvegarde et les slots de réplication en même temps.

Note : l’argument --write-recovery-conf en version PostgreSQL 12 créera un fichier standby.signal et modifiera le fichier postgresql.auto.conf.

postgres@workshop12:~/12/data$ mkdir -p /opt/pgsql/backups
postgres@workshop12:~/12/data$ pg_basebackup --slot physical_slot1 --create-slot \
--write-recovery-conf -D /opt/pgsql/backups/

postgres@workshop12:~/12/data$ psql -x -c \
"SELECT * FROM pg_replication_slots"

-[ RECORD 1 ]-------+---------------
slot_name           | physical_slot1
plugin              | 
slot_type           | physical
datoid              | 
database            | 
temporary           | f
active              | f
active_pid          | 
xmin                | 
catalog_xmin        | 
restart_lsn         | 0/9000000
confirmed_flush_lsn |

Copie du slot de réplication

postgres@workshop12:~/12/repl_1$ psql -c \
"SELECT pg_copy_physical_replication_slot('physical_slot1','physical_slot2')"

pg_copy_physical_replication_slot 
------------
 (physical_slot2,)

postgres@workshop12:~/12/repl_1$ psql -c \
"select slot_name,restart_lsn,slot_type,active from pg_replication_slots"

   slot_name    | restart_lsn | slot_type | active 
----------------+-------------+-----------+--------
 physical_slot1 | 0/9000000   | physical  | f
 physical_slot2 | 0/9000000   | physical  | f
(2 rows)

rsync -r -p /opt/pgsql/backups/ /opt/pgsql/12/repl_1

rsync -r -p /opt/pgsql/backups/ /opt/pgsql/12/repl_2

Modification du slot de réplication sur le réplicat 2 en éditant le fichier postgresql.auto.conf et en modifiant le nom du slot.

primary_slot_name = 'physical_slot2'

Changer les ports des réplicats en éditant les fichiers postgresql.conf.

port=5434 # pour le premier réplicat
port=5435 # pour le second réplicat

Démarrage des instances répliquées.

postgres@workshop12:~/12$ pg_ctl -D /opt/pgsql/12/repl_1 start

Vérification des slots sur le primaire : on voit ici que le premier réplicat est actif avec le LSN A000148

postgres@workshop12:~/12$ psql -c \
"select slot_name,restart_lsn,slot_type,active from pg_replication_slots"

   slot_name    | restart_lsn | slot_type | active 
----------------+-------------+-----------+--------
 physical_slot1 | 0/A000148   | physical  | t
 physical_slot2 | 0/9000000   | physical  | f

Vérification de l’accès au réplicat 1.

workshop12:~/12$ psql -p5434 -c "select pg_is_in_recovery()"
pg_is_in_recovery 
------------
 t

Même chose pour le réplicat 2 .

Démarrage de l’instance

postgres@workshop12:~/12$ pg_ctl -D /opt/pgsql/12/repl_2 start

Vérification sur le primaire : on voit ici que le réplicat 2 est maintenant actif avec le même LSN que le réplicat 1.

postgres@workshop12:~/12$ psql -c \
"select slot_name,restart_lsn,slot_type,active from pg_replication_slots"

   slot_name    | restart_lsn | slot_type | active 
----------------+-------------+-----------+--------
 physical_slot1 | 0/A000148   | physical  | t
 physical_slot2 | 0/A000148   | physical  | t

Vérification de l’accès au réplicat 2.

postgres@workshop12:~/12$ psql -p5435 -c \
"select pg_is_in_recovery()"

pg_is_in_recovery 
------------
 t

Monitoring

Échantillon des requêtes dans les logs
Vues de progression pour CREATE INDEX, CLUSTER, VACUUM
Listing :
- des fichiers dans les répertoires status des archives des wals
- des fichiers temporaires
pg_stat_replication : timestamp du dernier message reçu du secondaire

Échantillon des requêtes dans les logs

log_transaction_sample_rate

Information de progression

pg_stat_progress_cluster
pg_stat_progress_create_index
pg_stat_progress_vacuum

Progression de l’opération CLUSTER

pg_stat_progress_cluster

lors de l’opération CLUSTER, la vue pg_stat_progress_cluster indique la progression de l’opération qui dans certains cas, peut être très longue.

On lance le traitement dans une session

$ CLUSTER tab USING tab_i_j_idx;
CLUSTER

On observe la progression dans une autre

$ SELECT
  phase,
  heap_tuples_scanned,
  heap_tuples_written
  FROM
    pg_stat_progress_cluster;
$ \watch 1

          jeu. 17 oct. 2019 18:20:05 CEST (every 1s)

        phase        | heap_tuples_scanned | heap_tuples_written 
---------------------+---------------------+---------------------
 index scanning heap |              890880 |              890880
(1 row)

           jeu. 17 oct. 2019 18:20:06 CEST (every 1s)

        phase        | heap_tuples_scanned | heap_tuples_written 
---------------------+---------------------+---------------------
 index scanning heap |             1640280 |             1640280

...

         jeu. 17 oct. 2019 18:20:23 CEST (every 1s)

      phase       | heap_tuples_scanned | heap_tuples_written 
------------------+---------------------+---------------------
 rebuilding index |            11000000 |            11000000
(1 row)

...

   jeu. 17 oct. 2019 18:20:47 CEST (every 1s)

 phase | heap_tuples_scanned | heap_tuples_written 
-------+---------------------+---------------------
(0 rows)

Progression de la création d’index

pg_stat_progress_create_index

Lors de la création d’ index, la progression est consultable dans la vue

pg_stat_progress_create_index :

$ CREATE INDEX ON a_table (i, a, b);

Dans une autre session, avant de lancer la création de l’index :

SELECT
  datname,
  relid::regclass,
  command,
  phase,
  tuples_done
FROM
  pg_stat_progress_create_index;


          ven. 26 juil. 2019 17:41:18 CEST (every 1s)

 datname | relid | index_relid | command | phase | tuples_done 
---------+-------+-------------+---------+-------+-------------
(0 rows)
$ \watch 1

                              ven. 26 juil. 2019 17:41:19 CEST (every 1s)


 datname  |  relid  |   command    |                 phase                  | tuples_done 
----------+---------+--------------+----------------------------------------+-------------
 postgres | a_table | CREATE INDEX | building index: loading tuples in tree |      718515
(1 row)

                              ven. 26 juil. 2019 17:41:20 CEST (every 1s)

 datname  |  relid  |   command    |                 phase                  | tuples_done 
----------+---------+--------------+----------------------------------------+-------------
 postgres | a_table | CREATE INDEX | building index: loading tuples in tree |     1000000
(1 row)

Progression de l’opération VACUUM

pg_stat_progress_vacuum

Depuis la version 11, dès qu’un VACUUM est en action, la vue pg_stat_progress_vacuum est renseignée pour informer de la progression de l’opération.

$ SELECT
   phase,
   heap_blks_vacuumed,
   index_vacuum_count,
   num_dead_tuples
 FROM
   pg_stat_progress_vacuum;


phase         | heap_blks_vacuumed | index_vacuum_count | num_dead_tuples 
--------------+--------------------+--------------------+-----------------
scanning heap |                  0 |                  0 |          997918
(1 row)

$ \watch 1
ven. 26 juil. 2019 18:21:03 CEST (every 1s)

phase          | heap_blks_vacuumed | index_vacuum_count | num_dead_tuples 
---------------+--------------------+--------------------+-----------------
scanning heap  |                  0 |                  0 |          997918
(1 row)

  ven. 26 juil. 2019 18:21:04 CEST (every 1s)

  phase           | heap_blks_vacuumed | index_vacuum_count | num_dead_tuples 
  ----------------+--------------------+--------------------+-----------------
vacuuming indexes |                  0 |                  0 |          997918
(1 row)

...

ven. 26 juil. 2019 18:21:21 CEST (every 1s)

phase          | heap_blks_vacuumed | index_vacuum_count | num_dead_tuples 
---------------+--------------------+--------------------+-----------------
vacuuming heap |               6577 |                  1 |          997918
(1 row)

ven. 26 juil. 2019 18:21:22 CEST (every 1s)

phase          | heap_blks_vacuumed | index_vacuum_count | num_dead_tuples 
---------------+--------------------+--------------------+-----------------
vacuuming heap |               9097 |                  1 |          997918
(1 row)

ven. 26 juil. 2019 18:21:23 CEST (every 1s)

phase          | heap_blks_vacuumed | index_vacuum_count | num_dead_tuples 
---------------+--------------------+--------------------+-----------------
vacuuming heap |              11620 |                  1 |          997918
(1 row)

ven. 26 juil. 2019 18:21:24 CEST (every 1s)

phase  | heap_blks_vacuumed | index_vacuum_count | num_dead_tuples 
-------+--------------------+--------------------+-----------------
(0 rows)

Archive status

pg_ls_archive_statusdir()

Liste le nom, taille et l’heure de la dernière modification des fichiers dans le dossier status de l’archive des WALs. Il faut être membre du group pg_monitor ou avoir explicitement le droit (pg_read_server_files).

À savoir que ce répertoire est peuplé lorsq’un journal de transaction (wal) est archivé par l’archive_command.

$ SELECT pg_switch_wal ();
$ SELECT pg_switch_wal ();
$ SELECT pg_switch_wal ();
$ SELECT * FROM pg_ls_archive_statusdir ();


             name              | size |      modification      
-------------------------------+------+------------------------
 0000000100000001000000CB.done |    0 | 2019-09-03 11:51:39+02
 0000000100000001000000CD.done |    0 | 2019-09-09 14:14:48+02
 0000000100000001000000CC.done |    0 | 2019-09-09 14:14:48+02
(3 rows)

Fichiers temporaires

pg_ls_tmpdir()

La supervision des fichiers temporaires est désormais possible dans une session :

$ select * from pg_ls_tmpdir();
      name       |    size    |      modification      
-----------------+------------+------------------------
 pgsql_tmp8686.4 | 1073741824 | 2019-09-09 14:18:29+02
 pgsql_tmp8686.3 | 1073741824 | 2019-09-09 14:18:19+02
 pgsql_tmp8686.2 | 1073741824 | 2019-09-09 14:18:13+02
 pgsql_tmp8686.5 |  456941568 | 2019-09-09 14:18:31+02
 pgsql_tmp8686.1 |   26000000 | 2019-09-09 14:17:56+02
 pgsql_tmp8686.0 | 1073741824 | 2019-09-09 14:18:05+02
(6 rows)

Ajout dans la vue pg_stat_replication

timestamp du dernier message reçu du standby

Dans le cadre de la supervision de la réplication, il est possible de déterminer l’heure à laquelle un secondaire en standby a communiqué pour la dernière fois, avec le primaire.

$ SELECT * FROM pg_stat_replication;

Administration

Nouveautés sur le VACUUM
Recyclage des WALs
Environnement client : PG_COLORS, EXPLAIN SETTINGS,
Outils : pg_upgrade, pg_ctl, pg_checksums
Paramètres de postgresql.conf

Nouveautés du VACUUM

VACUUM TRUNCATE
Nouvelles options de vacuumdb
SKIP_LOCKED
INDEX_CLEANUP

VACUUM TRUNCATE (reprendre un TP existant dans les manuels)

Nouvel attribut de table : VACUUM_TRUNCATE.

Cet attribut à ON par défaut permet de tronquer l’espace vide à la fin de la table (Fonctionnement par défaut de la version PostgreSQL 11).

Positionner l’attribut de table VACUUM_TRUNCATE = OFF permet d’ignorer l’opération de tronquage.

L’option TRUNCATE a également été ajoutée à l’instruction VACUUM .

Exemple :

L’exemple suivant permet de ne pas tronquer la table à la fin du vacuum.

pg12=# VACUUM (TRUNCATE ON) t1;
VACUUM

Nouvelles Options de vaccumdb

--min-xid-age
--min-mxid-age
--disable-page-skipping
--skip-locked

VACUUM SKIP_LOCK

Plus d’attente de verrou

En PostgreSQL 11, lors d’un VACUUM ou d’un ANALYZE sur une table verrouillée, le processus attendait que la table soit déverrouillée pour continuer son traitement.

En PostgreSQL 12 l’option SKIP_LOCKED permet d’ignorer les tables verrouillées. Si une table verrouillée est ignorée, un WARNING est écrit dans le fichier de traces.

Exemple :

pg12=# VACUUM (VERBOSE, SKIP_LOCKED) t1;
psql: WARNING:  skipping vacuum of "t1" --- lock not available
VACUUM

VACUUM_INDEX_CLEANUP

VACUUM : pas les index

Sur la commande VACUUM, l’option INDEX_CLEANUP = OFF permet de désactiver le vacuum sur l’index. Dans le cas où l’option n’est pas spécifiée, le processus prendra en compte le paramètre VACUUM_INDEX_CLEANUP de la table. Par défaut VACUUM_INDEX_CLEANUP est à on.

pg12=# VACUUM (VERBOSE ON, INDEX_CLEANUP OFF) t1 ;
psql: INFO: vacuuming "public.t1"
psql: INFO: "t1": found 0 removable, 0 nonremovable row versions in 0
out of 0 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 259
There were 0 unused item pointers.
Skipped 0 pages due to buffer pins, 0 frozen pages.
0 pages are entirely empty.
0 tuples and 0 item identifiers are left as dead.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUM

Le paramètre VACUUM_INDEX_CLEANUP peut être configuré à OFF sur une table pour désactiver les vacuum des index.

pg12=# ALTER TABLE t1 SET (VACUUM_INDEX_CLEANUP=OFF);
ALTER TABLE
pg12=# \d+ t1
                                    Table "public.t1"
 Column |  Type   | Collation | Nullable | Default | Storage | Stats target | Description 
--------+---------+-----------+----------+---------+---------+--------------+-------------
 id     | integer |           |          |         | plain   |              | 
Access method: heap
Options: vacuum_index_cleanup=off

Nouvelles options pour les journaux de transactions

wal_recycle
wal_init_zero

Environnement Client

Variable PG_COLOR et PG_COLORS
Formatage CSV en sortie du psql
EXPLAIN (SETTINGS)

Variables d’environnement PG_COLOR et PG_COLORS

Les nouvelles variables d’environnement (client) PG_COLOR et PG_COLORS permettent d’ajouter et de personnaliser une coloration des erreurs, warning, log à la sortie de la commande psql.

Format de sortie CSV (\pset ouput CSV)

PostgreSQL 12 permet de formater la sortie de la commande psql au format CSV format.

Il existe 2 façons de changer le format de sortie :

1 - Ajouter le paramètre --csv à la ligne de commande psql

Exemple :

$ psql --csv -c "select name,setting,source,boot_val from pg_settings limit 1;"
name,setting,source,boot_val
allow_system_table_mods,off,default,off

2 - Exécuter \\pset format csv dans l’interpréteur psql.

Exemple :

pg12=# select name,setting,source,boot_val from pg_settings limit 1;
          name           | setting | source  | boot_val 
-------------------------+---------+---------+----------
 allow_system_table_mods | off     | default | off
(1 row)

pg12=# \\pset format csv
Output format is csv.

pg12=# select name,setting,source,boot_val from pg_settings limit 1;
name,setting,source,boot_val
allow_system_table_mods,off,default,off

Option SETTINGS pour EXPLAIN

L’option SETTINGS ON spécifiée lors de l’instruction EXPLAIN permet de générer des informations sur les paramètres liés au plan d’exécution.

Ces paramètres étant modifiés par rapport aux valeurs par défaut.

pg12=# SET enable_sort = off;
SET
pg12=# EXPLAIN (SETTINGS ON) SELECT * FROM t1 WHERE id = 50;
                    QUERY PLAN                    
--------------------------------------------------
 Seq Scan on t1  (cost=0.00..2.25 rows=1 width=4)
   Filter: (id = 50)
 Settings: enable_sort = 'off'

Outils

pg_upgrade --clone et pg_upgrade --socketdir
Rotation des logs avec pg_ctl logrotate
pg_checksums anciennement pg_verify_checksums

Options clone et socketdir de pg_upgrade

2 nouvelles options ont été ajoutées à la commande pg_upgrade.

--clone

Ce paramètre permet à la commande pg_upgrade d’effectuer un clonage à l’aide des liens reflink. L’utilisation de ce paramètre dépend du système d’exploitation et du système de fichiers.
--socketdir ou -s

Ce paramètre permet de spécifier un répertoire pour la création d’une socket locale.

Rotation des logs avec pg_ctl

En PostgreSQL 11, la rotation des logs se faisait en envoyant un signal SIGUP au processus de log. En PostgreSQL 12 le paramètre logrotate a été ajouté à la commande pg_ctl.

Exemple :

postgres@workshop12:~/12/data$ pg_ctl -D /opt/pgsql/12/data/ logrotate
server signaled to rotate log file

Renommage de pg_verify_checksums en pg_checksums

pg_verify_checksum renomée en pg_checksums
Activation, désactivation des checksums

La commande pg_verify_checksums (ajoutée en PostgreSQL 11) est renommée en pg_checksums. Cette commande permet de vérifier l’intégrité de la totalité des fichiers de l’instance PostgreSQL.

La commande permet également d’activer pg_checksums -e ou de désactiver pg_checksums -d les sommes de contrôle dans l’instance. En PostgreSQL 11, il était impossible de changer ce statut,sans réinstaller l’instance.

Attention, l’instance doit être arrêtée pour toutes actions de la commande pg_checksums.

Exemple :

postgres@workshop12:~/12/data$ pg_checksums
pg_checksums: error: cluster must be shut down

postgres@workshop12:~/12/data$ pg_ctl -D /opt/pgsql/12/data/ stop
waiting for server to shut down.... done
server stopped

postgres@workshop12:~/12/data$ pg_checksums
Checksum operation completed
Files scanned:  1563
Blocks scanned: 4759
Bad checksums:  0
Data checksum version: 1

postgres@workshop12:~/12/data$ pg_checksums -d
pg_checksums: syncing data directory
pg_checksums: updating control file
Checksums disabled in cluster

postgres@workshop12:~/12/data$ pg_checksums
pg_checksums: error: data checksums are not enabled in cluster

postgres@workshop12:~/12/data$ pg_checksums -e
Checksum operation completed
Files scanned:  1563
Blocks scanned: 4759
pg_checksums: syncing data directory
pg_checksums: updating control file
Checksums enabled in cluster

Paramètres postgresql.conf

Nouveaux paramètres
Paramètres modifiés
Paramètres dont la valeurs par défaut a été modifiée

Nouveaux paramètres du fichier postgresql.conf

Les paramètres par défaut sont entre parenthèses.

Paramètre	Commentaire	Context
archive_cleanup_command	Anciennement dans le fichier recovery.conf	sighup
data_sync_retry (off)		postmaster
default_table_access_method (heap)	Spécifie la méthode d’accès aux tables par
	défaut à utiliser lors de la création de tables.
log_statement_sample_rate (1)		superuser
log_transaction_sample_rate (0)		superuser
plan_cache_mode (auto)	Change le comportement du cache des plans d’exécution	user
	(auto`,`force_custom_plan, force_generic_plan)
primary_conninfo	Anciennement dans le fichier recovery.conf	postmaster
primary_slot_name	Anciennement dans le fichier recovery.conf	postmaster
promote_trigger_file	Anciennement dans le fichier recovery.conf	sighup
recovery_end_command	Anciennement dans le fichier recovery.conf	sighup
recovery_min_apply_delay (0)	Anciennement dans le fichier recovery.conf	sighup
recovery_target	Anciennement dans le fichier recovery.conf	postmaster
recovery_target_action (pause)	Anciennement dans le fichier recovery.conf	postmaster
recovery_target_inclusive (on)	Anciennement dans le fichier recovery.conf	postmaster
recovery_target_lsn	Anciennement dans le fichier recovery.conf	postmaster
recovery_target_name	Anciennement dans le fichier recovery.conf	postmaster
recovery_target_time	Anciennement dans le fichier recovery.conf	postmaster
recovery_target_timeline (lastest)	Anciennement dans le fichier recovery.conf	postmaster
recovery_target_xid	Anciennement da7ns le fichier recovery.conf	postmaster
restore_comand	Anciennement dans le fichier recovery.conf	postmaster
shared_memory_type	Type de mémoire partagée, les valeurs possibles	postmaster
	dépendent du système d’exploitation
ssl_library	Nom de la librairie fournissant les fonctions SSL	internal
ssl_max_protocol_version	Version Max du protocole SSL supporté	sighup
ssl_min_protocol_version (TLSv1)	Version Min du protocole SSL supporté	sighup
tcp_user_timeout (0)		user
wal_init_zero (on)	Rempli les nouveaux fichiers WAL de zéros	superuser
wal_recycle (on)	Recycle les WAL	superuser

Paramètres modifiés

Paramètre	Changements
autovacuum_vacuum_cost_delay	Le type change de integer à real
client_min_messages
default_with_oids	Existe toujours mais ne peut pas être à on.
	(suppression des oid)
dynamic_shared_memory_type	Option “none” supprimée
log_autovacuum_min_duration	Contenu du journal applicatif change en
	fonction de l’exécution du vaccum
log_connections	Les informations de “application_name” peuvent
	être ajoutée dans les lignes du journal applicatif
recovery_target_timeline	L’option “current” a été ajoutée et la nouvelle
	valeur par défaut est “latest”
trace_sort	Le message de sortie change dans le journal applicatif
wal_level	Le démarrage de l’instance vérifie si le paramètre
	wal_level est bien renseigné
wal_sender_timeout	Contexte de modification passe de sighup à user

Paramètres ayant une nouvelle valeur par défaut.

Paramètre	PostgreSQL 11	PostgreSQL 12
autovacuum_vacuum_cost_delay	20	2
extra_float_digits	0	1
jit	OFF	ON
recovery_target_timeline		latest
transaction_isolation	default	read committed

Performances

REINDEX CONCURRENTLY
CREATE STATISTICS pour les distributions non-uniformes
plan_cache_mode
fonctions d’appui : pour améliorer les estimations de coût des fonctions
JIT par défaut
Optimisation CTE : MATERIALIZED / NOT MATERIALIZED
Meilleures performances sur le partitionnement

REINDEX CONCURRENTLY

REINDEX CONCURRENTLY

La commande REINDEX peut être maintenant suivie de l’option CONCURRENTLY, afin de permettre la réindexation d’un index en parallèle de son utilisation en limitant le verrouillage des pages. REINDEX CONCURRENTLY crée un nouvel index temporaire et remplace l’ancien index (renommage) une fois la réindexation terminée.

Exemple :

pg12=$ REINDEX (VERBOSE) TABLE CONCURRENTLY t1;
psql: INFO:  index "public.idx_t1_id" was reindexed
psql: INFO:  table "public.t1" was reindexed
DETAIL:  CPU: user: 1.97 s, system: 0.71 s, elapsed: 3.48 s.
REINDEX

L’option existe également pour la commande shell reindexdb (--concurrently).

Exemple :

$ reindexdb --dbname pg12 --concurrently --table t1 --verbose
INFO:  index "public.idx_t1_id" was reindexed
INFO:  table "public.t1" was reindexed
DETAIL:  CPU: user: 1.74 s, system: 0.69 s, elapsed: 3.23 s.

CREATE STATISTICS option mcv

CREATE STATISTICS avec most common values

L’option mcv dans la commande CREATE STATISTICS, permet de créer des statistiques avec les valeurs les plus communes pour plusieurs colonnes. Les statistiques sont stockées dans la table pg_statistic_ext.

Exemple :

pg12=$ CREATE TABLE t4 (id INT, nb NUMERIC, comm varchar(50));
CREATE TABLE

pg12=$ CREATE STATISTICS stat_mcv_t4(mcv) ON id, nb FROM t4 ;
CREATE STATISTICS

pg12=$ select * from pg_statistic_ext;
  oid  | stxrelid |   stxname   | stxnamespace | stxowner | stxkeys | stxkind 
-------+----------+-------------+--------------+----------+---------+---------
 41010 |    41003 | stat_mcv_t4 |         2200 |       10 | 1 2     | {m}
(1 row)

Mise en cache des plans d’exécution

plan_cache_mode

Fonctions d’appui (support functions)

Améliorer l’estimation du coût d’une fonction

JIT par défaut

JIT (Just-In-time) est maintenant active par défaut

Modification du comportement par défaut des requêtes CTE

CTE MATERIALIZED / NOT MATERIALIZED

En PostgreSQL 11 les requêtes CTE (Common Table Expression) spécifiées dans la clause WITH étaient materialisées (MATERIALIZED).

En PostgreSQL 12, le comportement n’est plus le même, par défaut, les requêtes CTE ne sont pas matérialisées (NOT MATERIALIZED).

Il est maintenant possible de spécifier dans la clause WITH, MATERIALIZED ou NOT MATERIALIZED.

Par exemple, le fait de spécifier l’option NOT MATERIALIZED, permet à la clause WHERE de pousser les restrictions à l’intérieur de la clause WITH.

Les conditions des requêtes pour l’application de l’option NOT MATERIALIZED sont :

requêtes non récursives
requêtes référencées une seule fois
requêtes n’ayant aucun effet de bord

Exemple : dans cet exemple on voit que l’index est utilisé ce qui réduit le temps d’exécution.

pg12=$ EXPLAIN ANALYSE WITH rq AS MATERIALIZED (SELECT * FROM t1) 
SELECT * FROM rq WHERE id =1500;

                                                 QUERY PLAN                                     
-------------------------------------------------------------------------------------------------
 CTE Scan on rq  (cost=133470.68..201273.71 rows=15067 width=4) 
(actual time=19.185..7067.369 rows=4 loops=1)
   Filter: (id = 1500)
   Rows Removed by Filter: 3100096
   CTE rq
     ->  Seq Scan on t1  (cost=0.00..133470.68 rows=3013468 width=4) 
(actual time=4.311..3749.203 rows=3100100 loops=1)
 Planning Time: 0.195 ms
 Execution Time: 7073.119 ms

La même requête avec l’option NOT MATERIALIZED (valeur par défaut si l’option n’est pas spécifiée)

pg12=$ EXPLAIN ANALYSE WITH rq AS NOT MATERIALIZED (SELECT * FROM t1) 
SELECT * FROM rq WHERE id =1500;
                                                 QUERY PLAN                                     
-------------------------------------------------------------------------------------------------
 Index Only Scan using idx_t1_id on t1  (cost=0.43..15.26 rows=3 width=4) 
(actual time=0.184..0.245 rows=4 loops=1)
   Index Cond: (id = 1500)
   Heap Fetches: 0
 Planning Time: 0.209 ms
 Execution Time: 0.338 ms

Performances du partitionnement

Grand nombre de partitions : mieux supporté
Verrous lors des manipulations de partitions

Incompatibilités

Disparition du recovery.conf
max_wal_senders n’est plus inclus dans max_connections
Noms des clés étrangères
Tables WITH OIDS n’existe plus
Types de données supprimés
Fonctions to_timestamp et to_date
pg_checksums

Disparition du fichier recovery.conf.

`max_wal_senders` n’est plus inclus dans max_connections

Noms des clés étrangères autogénérées

La génération automatique des noms de clés étrangères, prend désormais en compte le nom de toutes les colonnes de la clé. Cela peut entrainer une incompatibilité dans certains scripts qui se basent sur le nom des clés étrangères générées par PostgreSQL avec une colonne.

Exemple :

pg12=> CREATE TABLE t2(id INT, id2 INT, comm VARCHAR(50),
FOREIGN KEY (id, id2) REFERENCES t1(id, id2)) ;
CREATE TABLE
postgres=> \d t2
Table "public.t2"
 Column |         Type          | Collation | Nullable | Default 
--------+-----------------------+-----------+----------+---------
 id     | integer               |           |          | 
 id2    | integer               |           |          | 
 comm   | character varying(50) |           |          | 
Foreign-key constraints:
    "t2_id_id2_fkey" FOREIGN KEY (id, id2) REFERENCES t1(id, id2)

WITH OIDS clause deleted

L’option WITH OIDS (instruction CREATE TABLE) est supprimée. Il n’est plus possible de créer des tables avec des OID.

L’option WITHOUT OIDS est toujours supportées, et le paramètre default_with_oids est à off et reste invariable (plus possible de le mettre à on).

Exemple: impossible de crééer une table avec WITH OIDS

pg12=#  CREATE TABLE t3(id INT) WITH OIDS ;
psql: ERROR:  syntax error at or near "OIDS"
LINE 1: CREATE TABLE t3(id INT) WITH OIDS ;

Un SELECT * sur les anciennes tables créée avec WITH OIDS, affichera une colonne supplémentaire nommée oid.

Exemple : la table pg_class à une colonne oid visible

pg12=#  postgres=# \d pg_class
                     Table "pg_catalog.pg_class"
       Column        |     Type     | Collation | Nullable | Default 
---------------------+--------------+-----------+----------+---------
 oid                 | oid          |           | not null | 
 relname             | name         |           | not null | 
 relnamespace        | oid          |           | not null | 
 reltype             | oid          |           | not null | 
 .......

L’option -o ou --oids de la commande pg_dump a également été supprimée.

Type de données supprimés

Fonctions to_timestamp et to_date

Les espaces inutiles sont supprimés dans les modèles de formatage des fonctions to_timestamp et to_date.

Exemple :

En PostgreSQL 11 cette appel de fonction renvoye une erreur ou un résultat éronné.

pg12=> SELECT TO_DATE('2019/08/25', ' YYYY/MM/DD') ;
  to_date
------------
0019-08-25

pg12=> SELECT TO_DATE('2019/08/25', ' YYYY/  MM/DD') ;
ERREUR:  valeur « /2 » invalide pour « MM »
DÉTAIL : La valeur doit être un entier

En PostgreSQL 12, les espaces inutiles sont ignorés.

pg12=> SELECT TO_DATE('2019/08/25', ' YYYY/MM/DD') ;
  to_date
------------
2019-08-25

pg12=> SELECT TO_DATE('2019/08/25', ' YYYY/  MM/DD') ;
  to_date
------------
2019-08-25

`pg_verify_checksums` renomée en `pg_checkums`

Fonctionnalités futures

Pluggable storage
- HEAP storage
- column storage
- Zed Heap
- blackhole

Pluggable storage

HEAP storage

HEAP storage : méthode par défaut

Column storage

méthode orientée colonne

zHeap

meilleur contrôle du bloat
réduction de l’amplification des écritures
réduction de la taille des entêtes
méthode basée sur les différences

Méthode d’accès Blackhole

sert de base pour créer une extension Access Method
toute donnée ajoutée est envoyée dans le néant

Cette extension écrite par Michael Paquier, fournit une base pour l’écriture des extensions pour les méthodes d’accès. Toutes les données sont envoyées dans le néant.

$ CREATE EXTENSION blackhole_am;
CREATE EXTENSION
$ \dx+ blackhole_am
   Objects in extension "blackhole_am"
           Object description
-----------------------------------------
 access method blackhole_am
 function blackhole_am_handler(internal)
(2 rows)

$ CREATE TABLE blackhole_tab (id int) USING blackhole_am;
CREATE TABLE
$ INSERT INTO blackhole_tab VALUES (generate_series(1,100));
INSERT 0 100
$ SELECT * FROM blackhole_tab;
 id
----
(0 rows)

Ateliers

TP sur les Colonnes générées

-- définition de la table

$ CREATE TABLE table1(
    id serial PRIMARY KEY,
    a int NOT NULL DEFAULT 0,
    b int NOT NULL DEFAULT 0,
    prod int generated always as (a * b) stored
) ;

$ \d table1
Table "public.table1"
Column |  Type   | Collation | Nullable |              Default               
--------+---------+-----------+----------+------------------------------------
id     | integer |           | not null | nextval('table1_id_seq'::regclass)
a      | integer |           | not null | 0
b      | integer |           | not null | 0
prod   | integer |           |          | generated always as (a * b) stored
Indexes:
"table1_pkey" PRIMARY KEY, btree (id)


-- insertion

INSERT INTO table1 (a,b) VALUES (6,7) ;
SELECT * FROM table1 ;

 id | a | b | prod 
----+---+---+------
</div>
  1 | 6 | 7 |   42
(1 row)

Le système du MVCC fait qu’une mise à jour est en fait une insertion


-- Mise à jour

UPDATE table1 SET a=7 WHERE a=6;
SELECT * FROM table1 ;

Le champ prod est recalculé

 id | a | b | prod 
----+---+---+------
  1 | 7 | 7 |   49
(1 row)

Tentative de modification de la colonne générée

$ UPDATE table1 SET prod = 43 ;
ERROR:  column "prod" can only be updated to DEFAULT
DETAIL:  Column "prod" is a generated column.

Valeur par défaut

$ UPDATE table1 SET prod = DEFAULT ;

TP sur le partitionnement

Clés étrangères
Fonctions
- pg_partition_root()
- pg_partition_ancestors()
- pg_partition_tree()
Tablespace des tables filles dans l’ordre CREATE TABLE
Commande \dP

Clés étrangères dans les tables partitionnées

Support des clés étrangères

Nous allons mettre en place une clé étrangère dans une tables partitionnée. La relation sera alors créée dans chacune des partitions de celle-ci.

Reprise de l’exemple du Workshop v10 :

$ CREATE TABLE lieu (id INT PRIMARY KEY, nom TEXT);
$ INSERT INTO lieu VALUES  (1,'Lyon'),(2,'Nantes'),(3,'Paris');
$ CREATE TABLE meteo (                                                            
   t_id INTEGER GENERATED BY DEFAULT AS IDENTITY,                               
   id_lieu INT REFERENCES lieu(id) NOT NULL,                                                          
   heure_mesure timestamp DEFAULT now(),                                        
   temperature real NOT NULL                                                    
 ) PARTITION BY RANGE (id_lieu, heure_mesure);                                     
CREATE TABLE meteo_lyon_201709 PARTITION of meteo FOR VALUES                    
   FROM (1, '2017-09-01 00:00:00') TO (1, '2017-10-01 00:00:00');         
CREATE TABLE meteo_lyon_201710 PARTITION of meteo FOR VALUES                    
   FROM (1, '2017-10-01 00:00:00') TO (1, '2017-11-01 00:00:00');         
CREATE TABLE meteo_nantes_201709 PARTITION of meteo FOR VALUES                  
   FROM (2, '2017-09-01 00:00:00') TO (2, '2017-10-01 00:00:00'); 
CREATE TABLE meteo_nantes_201710 PARTITION of meteo FOR VALUES                  
   FROM (2, '2017-10-01 00:00:00') TO (2, '2017-11-01 00:00:00'); 
CREATE TABLE meteo_paris_201709 PARTITION of meteo FOR VALUES                   
   FROM (3, '2017-09-01 00:00:00') TO (3, '2017-10-01 00:00:00');   
CREATE TABLE meteo_paris_201710 PARTITION of meteo FOR VALUES                   
   FROM (3, '2017-10-01 00:00:00') TO (3, '2017-11-01 00:00:00');

Nous utilisons une fonction pour peupler cette table :

$ CREATE OR REPLACE FUNCTION public.peuple_meteo()
 RETURNS text
 LANGUAGE plpgsql
AS $function$    
DECLARE    
   lieux integer[] := '{}';    
   v_lieu integer;    
   v_heure timestamp;    
   v_temperature real;    
   v_nb_insertions integer := 500000;    
   v_insertion integer;    
BEGIN    
   lieux[0]=1;    
   lieux[1]=2;    
   lieux[2]=3;    
   FOR v_insertion IN 1 .. v_nb_insertions LOOP    
      v_lieu=lieux[floor((random()*3))::int];    
      v_heure='2017-09-01'::timestamp    
                   + make_interval(days => floor((random()*60))::int,    
                              secs => floor((random()*86400))::int);    
      v_temperature:=round(((random()*14))::numeric+10,2);    
      IF EXTRACT(MONTH FROM v_heure) = 10 THEN    
          v_temperature:=v_temperature-4;    
      END IF;    
      IF EXTRACT(HOUR FROM v_heure) <= 9    
         OR EXTRACT(HOUR FROM v_heure) >= 20 THEN    
          v_temperature:=v_temperature-5;    
      ELSEIF EXTRACT(HOUR FROM v_heure) >= 12    
         AND EXTRACT(HOUR FROM v_heure) <= 17 THEN    
          v_temperature:=v_temperature+5;    
      END IF;    
      INSERT INTO meteo (id_lieu,heure_mesure,temperature)    
        VALUES (v_lieu,v_heure,v_temperature);    
   END LOOP;    
   RETURN v_nb_insertions||' mesures de température insérées';    
END;    
$function$;
CREATE FUNCTION

$ SELECT peuple_meteo();
              peuple_meteo              
----------------------------------------
 500000 mesures de température insérées
(1 row)

Fonctions d’information sur le partitionnement

pg_partition_root(regclass)
pg_partition_ancestors(regclass)
pg_partition_tree(regclass)

-- table mère d'une partition
$ SELECT pg_partition_root('meteo_nantes_201710');
 pg_partition_root 
-------------------
 meteo
(1 row)

-- ancêtres d'une partition (incluant la partition elle-même)
$ select pg_partition_ancestors('meteo_lyon_201709');
 pg_partition_ancestors 
------------------------
 meteo_lyon_201709
 meteo
(2 rows)

-- Arbre complet d'une table partitionnée
$ select * from pg_partition_tree('meteo');
        relid        | parentrelid | isleaf | level 
---------------------+-------------+--------+-------
 meteo               |             | f      |     0
 meteo_lyon_201709   | meteo       | t      |     1
 meteo_lyon_201710   | meteo       | t      |     1
 meteo_nantes_201709 | meteo       | t      |     1
 meteo_nantes_201710 | meteo       | t      |     1
 meteo_paris_201709  | meteo       | t      |     1
 meteo_paris_201710  | meteo       | t      |     1
(7 rows)

Tablespace des partitions dans l’ordre CREATE TABLE

Préciser le tablespace des tables filles dans l’ordre CREATE TABLE

Il est maintenant possible de choisir le tablespace d’une partition lors de sa création :

$ CREATE TABLESPACE tb1 LOCATION '/home/frbn/.pgenv/pgsql/tb1/';
$ CREATE TABLESPACE tb2 LOCATION '/home/frbn/.pgenv/pgsql/tb2/';
$ CREATE TABLE mere (i INT) PARTITION BY RANGE (i);
$ CREATE TABLE fille_1_10 PARTITION OF mere FOR VALUES FROM  (1) TO (5) TABLESPACE tb1;
$ CREATE TABLE fille_6_10 PARTITION OF mere FOR VALUES FROM  (6) TO (10) TABLESPACE tb2;

\dP : Affichage des tables partitionnées seules

$ \d
                   Liste des relations
 Schéma |    Nom     |        Type        | Propriétaire 
--------+------------+--------------------+--------------
 public | a_table    | table              | postgres
 public | fille_1_10 | table              | postgres
 public | fille_6_10 | table              | postgres
 public | mere       | table partitionnée | postgres
(4 lignes)

$ \dP
             Liste des relations partitionnées
 Schéma | Nom  | Propriétaire |        Type        | Table 
--------+------+--------------+--------------------+-------
 public | mere | postgres     | table partitionnée | 
(1 ligne)

TP Monitoring

échantillon des requêtes dans les logs
Vues de progression pour CREATE INDEX, CLUSTER, VACUUM
pg_ls_archive_statusdir() et pg_ls_tmpdir()
pg_stat_replication : timestamp du dernier message reçu du standby

Échantillon des requêtes dans les logs

log_statement_sample_rate
log_transaction_sample_rate

Activation des paramètres

Les deux paramètres sont à modifier dans le fichier postgresql.conf de l’instance :


# on récupère toute l'activité
log_min_duration_statement = 0

# 50% des requêtes
log_statement_sample_rate = 0.50

# 80% des transactions
log_transaction_sample_rate = 0.80

Vues de progression pour `CREATE INDEX`, `CLUSTER`, `VACUUM`

pg_stat_progress_create_index
pg_stat_progress_vacuum

pg_stat_progress_create_index

Lancer dans une sessions psql les commandes :

$ SELECT
  datname,
  relid::regclass,
  command,
  phase,
  tuples_done
FROM
  pg_stat_progress_create_index;

$ \watch 1

Lancer une réindexation dans une autre session :

$ CREATE TABLE a_table (
  i int,
  a text,
  b text
);

$ INSERT INTO a_table
SELECT
  i,
  md5(i::text),
  md5(i::text)
FROM
  generate_series(1, 100000) i;


$ CREATE INDEX ON a_table (i, a, b);

Observer les phases de la création de l’index dans la première session.

pg_stat_progress_vacuum

On se propose de suivre la progression des vacuum d’une base.

$ CREATE TABLE tab (i int , j text);
$ INSERT INTO tab SELECT i, md5(i::text)
  FROM generate_series(1,1000000) s(i);
$ DELETE FROM tab;
$ INSERT INTO tab SELECT i, md5(i::text)
  FROM generate_series(1,1000000) s(i);
-- L'autovacuum devrait se déclencher
$ SELECT * FROM pg_stat_progress_vacuum;
$ \watch 1

Archive status et fichiers temporaires

pg_ls_archive_statusdir()
pg_ls_tmpdir()

Déclenchez la rotation des journaux de transaction et donc l’archivage :

$ select pg_switch_wal();
$ select pg_switch_wal();
$ select pg_switch_wal();
$ select pg_ls_archive_statusdir();

                  pg_ls_archive_statusdir                   
------------------------------------------------------------
 (0000000100000001000000BC.done,0,"2019-07-29 14:12:08+02")
 (0000000100000001000000BB.done,0,"2019-07-29 14:11:36+02")
 (0000000100000001000000BD.done,0,"2019-07-29 14:12:15+02")
(3 rows)

Lancer une requête effectuant un tri assez conséquent pour dépasser la work_mem et créer des fichiers temporaires :

$ select pg_ls_tmpdir();
                     pg_ls_tmpdir                     
------------------------------------------------------
 (pgsql_tmp16064.9,24395776,"2019-07-29 14:05:49+02")
(1 row)

timestamp du dernier message reçu du standby

pg_stat_replication

Réplication sur le serveur primaire

Nous allons mettre en place une réplication logique entre deux instances v12.

Récupérer les sources, compiler installer dans /usr/local/pgsql. Créer un répertoire 12 dans le home de l’utilisateur et initialiser un cluster dedans :

$ /usr/local/pgsql/bin/initdb -D data

Créer deux scripts simples de démarrage et d’arrêt :

#! /bin/bash
# start.sh

/usr/local/pgsql/bin/pg_ctl -D data -l logfile start

#! /bin/bash
# stop.sh

kill $(cat data/postmaster.pid | head -1)

Activation de la réplication logique sur le primaire :

postgresql.conf

wal_level = logical

création de l’utilisateur de réplication :

$ create user repli with password 'repli';
CREATE ROLE
$ alter user repli  with replication ;
$ grant select on all tables in schema public to repli;
GRANT

Création de la publication sur la table a_table :

$ create table a_table (i int primary key, a text,b text);
$ insert into a_table select i,i::text,i::text from generate_series (1,1000000) i ;
$ create user repli with replication;
$ CREATE publication a_table_publication for table a_table;

pg_hba.conf

host all repli 127.0.0.1/32 md5

Création de la structure de la table répliquée depuis le serveur primaire :

$ pg_dump -s -t a_table -U postgres |/usr/local/pgsql/bin/psql -p 5412 postgres

Souscription sur le serveur secondaire

$ create subscription a_table_subscription 
CONNECTION 'host=127.0.0.1 port=5432 user=repli dbname=postgres password=repli' 
publication a_table_publication ;

Vérification de la Réplication

$ select usename,application_name,reply_time from pg_stat_replication ;
 usename |   application_name   |          reply_time           
---------+----------------------+-------------------------------
 repli   | a_table_subscription | 2019-07-30 12:14:41.934615+02
(1 row)

Nous avons l’heure exacte du dernier contact avec la souscription a_table_subscription.

TP Index et performances

Les fonctions d’appui
reindex concurrently

TP sur les fonctions d’appui

Modification des fonctions classiques

En regardant la définition de la fonction unnest(anyarray), on remarque que la v12 fait apparaître une fonction d’appui (support function en anglais) :

En v11


v11 $ \ef unnest(anyarray)

CREATE OR REPLACE FUNCTION pg_catalog.unnest(anyarray)
 RETURNS SETOF anyelement
 LANGUAGE internal
 IMMUTABLE PARALLEL SAFE STRICT ROWS 100 
AS $function$array_unnest$function$

En v12 :


v12 $ \ef unnest(anyarray)

CREATE OR REPLACE FUNCTION pg_catalog.unnest(anyarray)
 RETURNS SETOF anyelement
 LANGUAGE internal
 IMMUTABLE PARALLEL SAFE STRICT ROWS 100 SUPPORT array_unnest_support
AS $function$array_unnest$function$

Le rôle de la fonction d’appui peut être vérifié rapidement en comparant l’explain sous une version 11 et sous une version 12 :

v11 $ explain select * from unnest(array[0,1,2,3]);
                         QUERY PLAN                          
-------------------------------------------------------------
 Function Scan on unnest  (cost=0.00..1.00 rows=100 width=4)
(1 row)

On remarque que l’optimiseur fait une erreur en estimant le nombre de lignes retournées (100 plutôt que 4).

explain select * from unnest(array[0,1,2,3]);
                        QUERY PLAN                         
-----------------------------------------------------------
 Function Scan on unnest  (cost=0.00..0.04 rows=4 width=4)
(1 row)

La v12 estime bien le nombre de ligne car elle consulte la fonction d’appui.

Autre exemple avec la fonction generate_series(bigint,bigint)

v11 $ explain select generate_series(1,100000000);
                   QUERY PLAN
-------------------------------------------------
 ProjectSet  (cost=0.00..5.02 rows=1000 width=4)
   ->  Result  (cost=0.00..0.01 rows=1 width=0)
(2 rows)

v12 $ explain select generate_series(1,100000000);
                        QUERY PLAN
-----------------------------------------------------------
 ProjectSet  (cost=0.00..500000.02 rows=100000000 width=4)
   ->  Result  (cost=0.00..0.01 rows=1 width=0)
(2 rows)

La fonction generate_series a été modifiée :

v12 $ \ef generate_series(bigint,bigint)

CREATE OR REPLACE FUNCTION pg_catalog.generate_series(bigint, bigint)
 RETURNS SETOF bigint
 LANGUAGE internal
 IMMUTABLE PARALLEL SAFE STRICT SUPPORT generate_series_int8_support
AS $function$generate_series_int8$function$

La fonction d’appui est appelée par l’optimiseur, pour retourner une estimation du nombre de lignes qui est calculée en rapport avec les 2 entiers donnés en paramètres.

TP Reindex concurrently

Les tests sont à effectuer sur une instance de PostgreSQL 12 avec le paramétrage par défaut.

Créer 10 000 000 de lignes. La commande ci-dessous ajoute 10 milions d’enregistrements dans la table pgbench_accounts.

$ pgbench -i -s 100

Réindexer la table sans concurrently.

Exemple de résultat (sans concurrently) :

$ \time -f%E reindexdb -i pgbench_accounts_pkey
0:06.83
$ \time -f%E reindexdb -i pgbench_accounts_pkey
0:06.85
$ \time -f%E reindexdb -i pgbench_accounts_pkey
0:06.83

Réindexer la table avec concurrently.

Exemple de résultat (avec concurrently) :

$ \time -f%E reindexdb --concurrently -i pgbench_accounts_pkey
0:09.58
$ \time -f%E reindexdb --concurrently -i pgbench_accounts_pkey
0:09.40
$ \time -f%E reindexdb --concurrently -i pgbench_accounts_pkey
0:09.34

La réindexation classique est plus rapide car elle effectue moins d’opérations.

Lancer un test avec pgbench de 20 secondes en lecture et déclencher une réindexation 5 secondes après le début du bench.

$ (sleep 5; time -f%E reindexdb -i pgbench_accounts_pkey ) & pgbench -c1 -T20 -S -P1 -r

Exemple de résultat :

starting vacuum...end.
progress: 1.0 s, 6375.9 tps, lat 0.156 ms stddev 0.029
progress: 2.0 s, 6549.7 tps, lat 0.152 ms stddev 0.016
progress: 3.0 s, 6586.0 tps, lat 0.151 ms stddev 0.019
progress: 4.0 s, 6902.0 tps, lat 0.145 ms stddev 0.020
progress: 5.0 s, 6603.9 tps, lat 0.148 ms stddev 0.017
progress: 6.0 s, 0.0 tps, lat 0.000 ms stddev 0.000    <- reindex en cours
progress: 7.0 s, 0.0 tps, lat 0.000 ms stddev 0.000    <- reindex en cours
....
0:06.70                                                <- temps de reindex
progress: 12.0 s, 2324.2 tps, lat 3.022 ms stddev 138.282
progress: 13.0 s, 6684.0 tps, lat 0.149 ms stddev 0.028
... 
transaction type: <builtin: select only>
scaling factor: 100
query mode: simple
number of clients: 1
number of threads: 1
duration: 20 s
number of transactions actually processed: 89110
latency average = 0.224 ms
latency stddev = 22.327 ms
tps = 4455.484635 (including connections establishing)
tps = 4455.974731 (excluding connections establishing)
[1]+  Done                    ( sleep 5; \time -f%E reindexdb -i pgbench_accounts_pkey )

Lancer un test avec pgbench de 20 secondes en lecture et déclencher une reindexation avec concurrently 5 secondes après le début du bench.

$ (sleep 5; time -f%E reindexdb --concurrently -i pgbench_accounts_pkey ) & pgbench -c1 -T20 -S -P1 -r

Exemple de résultat :

starting vacuum...end.
progress: 1.0 s, 6346.8 tps, lat 0.156 ms stddev 0.029
progress: 2.0 s, 6688.0 tps, lat 0.149 ms stddev 0.016
progress: 3.0 s, 6471.9 tps, lat 0.154 ms stddev 0.053
progress: 4.0 s, 6730.9 tps, lat 0.148 ms stddev 0.025
progress: 5.0 s, 6723.0 tps, lat 0.148 ms stddev 0.021
progress: 6.0 s, 4546.0 tps, lat 0.219 ms stddev 0.047  <- reindex concurrently en cours
progress: 7.0 s, 4472.2 tps, lat 0.223 ms stddev 0.090  <- reindex concurrently en cours
progress: 8.0 s, 4557.0 tps, lat 0.219 ms stddev 0.067  <- reindex concurrently en cours
...
0:10.62                                                 <- temps de reindex
progress: 16.0 s, 6221.7 tps, lat 0.160 ms stddev 0.039
progress: 17.0 s, 6655.3 tps, lat 0.150 ms stddev 0.017
...
transaction type: <builtin: select only>
scaling factor: 100
query mode: simple
number of clients: 1
number of threads: 1
duration: 20 s
number of transactions actually processed: 120522
latency average = 0.165 ms
latency stddev = 0.150 ms
tps = 6026.060490 (including connections establishing)
tps = 6027.885412 (excluding connections establishing)
[1]+  Done             ( sleep 5; \time -f%E reindexdb --concurrently -i pgbench_accounts_pkey )

Lancer un test avec pgbench de 20 secondes en écriture et déclencher une reindexation 5 secondes après le début du bench.

$ (sleep 5; \time -f%E reindexdb -i pgbench_accounts_pkey ) & pgbench -c1 -T20 -P1 -r

Exemple de résultat :

starting vacuum...end.
progress: 1.0 s, 146.0 tps, lat 6.769 ms stddev 1.448
progress: 2.0 s, 155.0 tps, lat 6.468 ms stddev 1.254
progress: 3.0 s, 129.0 tps, lat 7.773 ms stddev 1.439
progress: 4.0 s, 129.0 tps, lat 7.704 ms stddev 1.415
progress: 5.0 s, 156.0 tps, lat 6.310 ms stddev 1.235
progress: 6.0 s, 0.0 tps, lat 0.000 ms stddev 0.000 <- reindex en cours
progress: 7.0 s, 0.0 tps, lat 0.000 ms stddev 0.000
....
0:07.70
progress: 13.0 s, 48.0 tps, lat 167.134 ms stddev 1094.662
progress: 14.0 s, 126.0 tps, lat 7.894 ms stddev 1.741
progress: 15.0 s, 143.0 tps, lat 7.015 ms stddev 1.629
...
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 100
query mode: simple
number of clients: 1
number of threads: 1
duration: 20 s
number of transactions actually processed: 1746
latency average = 11.454 ms
latency stddev = 183.386 ms
tps = 87.274426 (including connections establishing)
tps = 87.294817 (excluding connections establishing)
statement latencies in milliseconds:
           0.004  \set aid random(1, 100000 * :scale)
           0.001  \set bid random(1, 1 * :scale)
           0.001  \set tid random(1, 10 * :scale)
           0.001  \set delta random(-5000, 5000)
           0.145  BEGIN;
           4.907  UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
           0.320  SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
           0.419  UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
           0.367  UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
           0.269  INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
           5.020  END;
  [1]+  Done                    ( sleep 5; \time -f%E reindexdb -i pgbench_accounts_pkey )

Lancer un test avec pgbench de 20 secondes en écriture et déclencher une reindexation avec concurrently 5 secondes après le début du bench.

$ (sleep 5; time -f%E reindexdb --concurrently -i pgbench_accounts_pkey ) & pgbench -c1 -T20 -P1 -r

Exemple de résultat :

progress: 1.0 s, 155.0 tps, lat 6.412 ms stddev 1.510
progress: 2.0 s, 142.0 tps, lat 7.039 ms stddev 1.780
progress: 3.0 s, 126.0 tps, lat 7.955 ms stddev 1.673
progress: 4.0 s, 130.0 tps, lat 7.665 ms stddev 1.640
progress: 5.0 s, 146.0 tps, lat 6.870 ms stddev 1.580
progress: 6.0 s, 147.0 tps, lat 6.762 ms stddev 1.278
progress: 7.0 s, 144.0 tps, lat 6.934 ms stddev 1.284
...

0:11.89
progress: 17.0 s, 157.0 tps, lat 6.321 ms stddev 1.546
progress: 18.0 s, 139.0 tps, lat 7.188 ms stddev 1.555
progress: 19.0 s, 145.0 tps, lat 6.944 ms stddev 3.168
progress: 20.0 s, 147.0 tps, lat 6.768 ms stddev 1.444
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 100
query mode: simple
number of clients: 1
number of threads: 1
duration: 20 s
number of transactions actually processed: 2740
latency average = 7.297 ms
latency stddev = 6.863 ms
tps = 136.994259 (including connections establishing)
tps = 137.018048 (excluding connections establishing)
[1]+  Done                    ( sleep 5; \time -f%E reindexdb --concurrently -i pgbench_accounts_pkey)

Nouveautés de PostgreSQL® 12

Nouveautés de PostgreSQL 12

Les nouveautés

Développement / SQL

Ajout du support des colonnes générées

Restriction

Visibilité de la colonne OID

COMMIT AND CHAIN / ROLLBACK AND CHAIN

COPY FROM WHERE…

Partitionnement

Clés étrangères dans les tables partitionnées

Fonctions d’information sur le partitionnement

Commande psql pour les tables partitionnées

Réplication

Nouveauté de postgresql.conf et recovery.conf

2 fichiers trigger

Paramètres modifiables à chaud

Fonction pg_promote()

Copie de slot de réplication

Monitoring

Échantillon des requêtes dans les logs

Information de progression

Progression de l’opération CLUSTER

Progression de la création d’index

Progression de l’opération VACUUM

Archive status

Fichiers temporaires

Ajout dans la vue pg_stat_replication

Administration

Nouveautés du VACUUM

Nouvelles Options de vaccumdb

VACUUM SKIP_LOCK

VACUUM_INDEX_CLEANUP

Nouvelles options pour les journaux de transactions

Environnement Client

Outils

Renommage de pg_verify_checksums en pg_checksums

Paramètres postgresql.conf

Performances

REINDEX CONCURRENTLY

CREATE STATISTICS option mcv

Mise en cache des plans d’exécution

Fonctions d’appui (support functions)

JIT par défaut

Modification du comportement par défaut des requêtes CTE

Performances du partitionnement

Incompatibilités

Disparition du fichier recovery.conf.

max_wal_senders n’est plus inclus dans max_connections

Noms des clés étrangères autogénérées

WITH OIDS clause deleted

Type de données supprimés

Fonctions to_timestamp et to_date

pg_verify_checksums renomée en pg_checkums

Fonctionnalités futures

Pluggable storage

HEAP storage

Column storage

zHeap

Méthode d’accès Blackhole

Ateliers

TP sur les Colonnes générées

TP sur le partitionnement

Clés étrangères dans les tables partitionnées

Fonctions d’information sur le partitionnement

Tablespace des partitions dans l’ordre CREATE TABLE

\dP : Affichage des tables partitionnées seules

TP Monitoring

Échantillon des requêtes dans les logs

Vues de progression pour CREATE INDEX, CLUSTER, VACUUM

Archive status et fichiers temporaires

timestamp du dernier message reçu du standby

TP Index et performances

TP sur les fonctions d’appui

TP Reindex concurrently

Nouveauté de `postgresql.conf` et `recovery.conf`

`max_wal_senders` n’est plus inclus dans max_connections

`pg_verify_checksums` renomée en `pg_checkums`

Vues de progression pour `CREATE INDEX`, `CLUSTER`, `VACUUM`