PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 18/02/2016 11:32:12

Peters Alain
Membre

Vacuum

Bonjour , 

je suis un nouvel utilisateur Postgres , je me familiarise avec le produit.

J'ai créé une db dans laquelle on insert et delete pas mal de records .  La taille des tables augmentent donc considérablement .  Pour récupérer l'espace disk , je lance un Vacuum . 

Deux questions :

1) la table est lockée pendant le vacuum ,  y-a-t-il une possibilité de lancer un vacuum sans locker la table .

2) les indexes sont aussi recréés .  Est-il possible de ne pas générer les Wals pendant le vacuum et la création des indexes ?

Merci pour vos réponses

Hors ligne

#2 18/02/2016 11:50:24

gleu
Administrateur

Re : Vacuum

1. Ne pas faire de VACUUM FULL mais s'assurer qu'il y a suffisamment de VACUUM simple (soit par l'autovacuum soit par un cron).
2. Non. Les WAL sont là pour éviter tout risque de corruption.


Pour le dire plus simplement, le VACUUM FULL est une fausse solution dans 90% des cas.

Hors ligne

#3 18/02/2016 11:56:04

Peters Alain
Membre

Re : Vacuum

Merci pour l'info .

Je vais tester tout cela

Hors ligne

#4 18/02/2016 12:46:43

Peters Alain
Membre

Re : Vacuum

Bonjour,

j'ai killé un vaccuum full  et je m'aperçois que l'espace déjà utilisé par le vacuum n'est pas récupéré .  Comment identifier cet espace alloué temporairement par le vacuum .  Je voudrais le remover de mon disk .

Merci pour vos bons conseils

Hors ligne

#5 18/02/2016 12:56:34

rjuju
Administrateur

Re : Vacuum

Comment avez-vous arrêté le VACUUM FULL ?

Hors ligne

#6 18/02/2016 12:59:51

Peters Alain
Membre

Re : Vacuum

J'ai killé   le process vacuumdb .  Je sais que ce n'est pas très 'propre' mais dans le même temps je simulais un crash .

  Je ne l'aurais pas killé sur une db de production.

Hors ligne

#7 18/02/2016 20:03:01

gleu
Administrateur

Re : Vacuum

Tuer vacuumdb n'est en aucun cas un problème, c'est juste un client. Par contre, il est possible que la commande SQL ait continué un moment sur le serveur vu que ce dernier n'a pas été averti de la mort du client. Donc à mon avis, c'est juste temporaire. En tout cas, je ne vous conseille pas de supprimer quoi que ce soit vous-même. Il y a bien plus de chances de faire une bêtise que de réparer quelque chose (qui, à mon sens, n'est pas cassé).

Hors ligne

#8 19/02/2016 09:04:18

Peters Alain
Membre

Re : Vacuum

Merci pour vos réponses.
Effectivement la db n'est pas corrompue.  Je l'ai arrêtée et redémarrée sans problème .  Cependant je n'ai toujours pas récupéré mes 30 gigas . 
Ce sont probablement des fichiers temporaires créé par Vacuum .  Donc je réédite ma question : comment récupérer cet espace ?

Hors ligne

#9 19/02/2016 13:49:53

rjuju
Administrateur

Re : Vacuum

Je réitère également ma question : comment exactement avez vous tué ce processus ? kill -9 ? Etait-ce le processus client ou serveur ?


En partant  du principe que c'était un kill -9 du processus serveur, effectivement je pense que les fichiers en cours d'utilisation ne seront pas supprimés automatiqement, car c'est ce que qui est implicitement demandé avec un kill -9 d'un processus serveur.


Si vous voulez récupérer les fichiers, le moyen le plus sur serait un dump/restore. Vous pouvez sinon jouer avec la liste des fichiers présents dans la base ayant une extension .29 (en supposant que les 30 giga viennent d'un seul objet) et la liste des fichiers qui devraient être présents (colonne relfilenode de la table pg_class) par exemple. Mais si vous ne savez pas trop ce que vous faîtes, vous avez plus de chance de supprimer un mauvais fichier et donc corrompre votre instance.

Hors ligne

#10 19/02/2016 16:26:42

Peters Alain
Membre

Re : Vacuum

Bonjour,

effectivement j'ai killé par un kill -9 .  Merci pour vos infos .  Je regarde cela tranquillement . 

Bon we

Hors ligne

#11 19/02/2016 21:29:20

rjuju
Administrateur

Re : Vacuum

Ok. Pour information, vous pouvez arrêter une requête en cours d'exécution avec la fonction pg_cancel_backend(pid), ou tuer la connexion proprement avec pg_terminate_backend(pid). Si vous souhaitez vraiment utiliser kill, alors le signal par défaut (SIGTERM) sera correctement géré par postgres.

Hors ligne

Pied de page des forums