Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Vous pouvez effectuer un gel manuel sur une table pour laquelle un processus vacuum est déjà en cours. C'est utile si vous avez identifié une table avec un âge proche de 2 milliards de transactions (ou supérieur à tous les seuils que vous surveillez).
Les étapes suivantes sont fournies à titre informatif et il existe plusieurs variantes de ce processus. Par exemple, pendant le test, supposons que vous trouviez que la valeur du paramètre maintenance_work_mem
maintenance_work_mem
, mais vous devez également agir immédiatement et effectuer un processus vacuum sur la table concernée. La procédure suivante montre ce que vous devez faire dans cette situation.
Pour procéder manuellement au gel du processus vacuum
-
Ouvrez les deux sessions de la base de données contenant la table sur laquelle vous voulez effectuer le processus vacuum. Pour la seconde session, utilisez « écran » ou un autre utilitaire qui gère la session si votre connexion est abandonnée.
-
Dans la première session, obtenez le PID de la session autovacuum en cours d'exécution sur la table.
Exécutez la requête suivante pour obtenir le PID de la session autovacuum.
SELECT datname, usename, pid, current_timestamp - xact_start AS xact_runtime, query FROM pg_stat_activity WHERE upper(query) LIKE '%VACUUM%' ORDER BY xact_start;
-
Dans la deuxième session, calculez la quantité de mémoire dont vous avez besoin pour cette opération. Dans cet exemple, nous déterminons que nous pouvons nous permettre d'utiliser jusqu'à 2 Go de mémoire pour cette opération. Nous affectons donc 2 Go à
maintenance_work_mem
pour la session en cours. SET maintenance_work_mem='2 GB';
SET
-
Dans la deuxième session, émettez une commande
vacuum freeze verbose
pour la table. Le paramètre de mode détaillé est utile, car il vous permet de voir l'activité bien qu'il n'existe actuellement aucun rapport d'avancement de cette opération dans PostgreSQL.\timing on
Timing is on.
vacuum freeze verbose pgbench_branches;
INFO: vacuuming "public.pgbench_branches" INFO: index "pgbench_branches_pkey" now contains 50 row versions in 2 pages DETAIL: 0 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: index "pgbench_branches_test_index" now contains 50 row versions in 2 pages DETAIL: 0 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: "pgbench_branches": found 0 removable, 50 nonremovable row versions in 43 out of 43 pages DETAIL: 0 dead row versions cannot be removed yet. There were 9347 unused item pointers. 0 pages are entirely empty. CPU 0.00s/0.00u sec elapsed 0.00 sec. VACUUM Time: 2.765 ms
-
Au cours de la première session, si l'autovacuum bloquait la session d'aspiration, cela
pg_stat_activity
indique que votre sessionT
d'aspiration est en attente. Dans ce cas, mettez fin au processus d'aspiration automatique comme suit.SELECT pg_terminate_backend('the_pid');
Note
Certaines versions inférieures d'Amazon RDS Amazon ne peuvent pas mettre fin à un processus d'aspiration automatique à l'aide de la commande précédente et échouent avec l'erreur suivante :.
ERROR: 42501: must be a superuser to terminate superuser process LOCATION: pg_terminate_backend, signalfuncs.c:227
À ce stade, votre session commence. Autovacuum redémarre immédiatement car cette table est probablement la plus haute de sa liste de travail.
-
Lancez votre commande
vacuum freeze verbose
dans la session 2, puis terminez le processus autovacuum de la session 1.