Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Un de mes utilisateurs à effectué un VACUUM FULL sur sa base ce matin et j'ai constaté au niveau des logs
que plus personnes ne pouvaient se connecter à leur base.
Un postgresql:
- base 1
- base 2
- base n
__logs__
> debut du vacuum full
944822 2014-01-28 07:38:11 GMT [11285]: [31] xx.xx.xx.xx.xx user=userbase1,db=base 1LOG: process 11285 still waiting for AccessExclusiveLock on relation 1260 of database 0 after 1000.044 ms
944823 2014-01-28 07:38:11 GMT [11285]: [41] xx.xx.xx.xx.xx user=userbase1,db=base 1 STATEMENT: VACUUM FULL VERBOSE
> ensuite d'autres users tente de se connecter
944829 2014-01-28 07:38:12 GMT [11294]: [21] host_distant user=userbase2,db=base 2 LOG: process 11294 still waiting for AccessShareLock on relation 1260 of database 0 after 1000.287 ms
944830 2014-01-28 07:38:12 GMT [11295]: [21] host_distant user=userbase2,db=base 2 LOG: process 11295 still waiting for AccessShareLock on relation 1260 of database 0 after 1000.148 ms
944865 2014-01-28 07:39:11 GMT [11294]: [31] host_distant user=userbase2,db=base 2 FATAL: canceling authentication due to timeout
--
le user de la base 1 n'est pas admin et ne peux se connecter qu'à sa base...
questions:
Qu'est ce que la database 0 ?
Est ce conseillé de faire un vacuum full sur une base ?
ou doit ton effectuer table par table ?
Merci,
Hors ligne
Voici ce qu'il se passe. Vous lancez VACUUM FULL. Ce dernier réclame des verrous en accès exclusifs sur toutes les tables, dont pg_authid (OID 1260). Or cette dernière doit être bloquée par un autre processus. Les autres utilisateurs ne peuvent pas se connecter car, lorsque PostgreSQL essaie de lire la table pg_authid à la connexion, il ne peut pas vu que le VACUUM FULL a demandé un verrou exclusif. Bref, tout le monde est bloqué.
Il faudrait savoir qui bloque le VACUUM FULL. Un "SELECT pid FROM pg_locks WHERE relation=1260 AND granted" nous donnerait le pid, puis un "SELECT * FROM pg_stat_activity WHERE pid=<no_pid_precedente_requete>" nous indiquerait les infos sur la session bloquante (à noter que la colonne s'appelle peut-être procpid pour cette dernière requête si votre version de PostgreSQL est une 9.2 ou antérieure.
Guillaume.
Hors ligne
Merci,
Si le problème se reproduit j'executerai la requête.
aat
Hors ligne
Re:Bonjour,
J'ai reussi à reproduire le cas:
Ce matin j'avais un dump en cours + l'execution manuel par un user d'un vaccuum full.
Encore merci,
Hors ligne
Re: du coup
je me demande comment protéger mon serveur de prod.
interdire des actions de dump de 8h30 à 22h est ce possible ?
Cdt,
Hors ligne
Un dump via pg_dump ? normal, ça pose des verrous en accès partagé, incompatible avec les verrous en accès exclusif du VACUUM FULL, et du coup tout le monde reste bloqué derrière.
Pour l'interdiction, ça ne peut être qu'une règle interne. Mais la vraie bonne question est : pourquoi voulez-vous utiliser VACUUM FULL ?
Guillaume.
Hors ligne
Bonjour,
Il a effectué un Vac full pour rentre l'espace disque au system !
bref il ne savait pas qu'en detruisant une table l'espace était rendu au system !
Assadi,
Hors ligne
Pages : 1
