Forums PostgreSQL.fr

herve.lefebvre

Membre

Access*Lock sur table temporaire

Bonjour,

J'ai un problème chez une gros client.

Ils ont un applicatif qui fait du CREATE TEMP TABLE XXX, et qui ensuite a un DROP TABLE XXX qui se retrouve bloqué à cause d'accessexclusive/sharedlock posés sur la table.

Alors il y a forcément un truc qui m'échappe, mais de base je ne vois pas comment c'est possible, puisque la table n'est visible qu'au sein de la session qui l'a créée, donc il n'est théoriquement pas possible qu'elle soit encore verrouillée au moment de l'exécution du DROP. De plus un "select locktype,database,relname,page,tuple,virtualxid,transactionid,classid,objid,objsubid,virtualtransaction,pid,mode,granted from pg_locks a, pg_class b where a.relation=b.oid and relname ilike '%XXX%'" montre bien que c'est le virtualtransaction qui effectue le DROP qui possède les locks sur la table.

Du coup évidemment, nombreuses "orphan temp table" etc.

Si quelqu'un a une idée je suis preneur, parce que ça me laisse perplexe cette histoire.

Vous pensez qu'il y a un moyen que ce verrouillage provienne d'un hotstandby et/ou du mécanisme de réplication ?
Est-ce que un curseur non fermé pourrait laisser traîner des locks et empêcher un DROP par exemple ?

gleu

Administrateur

Re : Access*Lock sur table temporaire

Si quelqu'un a une idée je suis preneur, parce que ça me laisse perplexe cette histoire.

Vous êtes certain que le verrou soit sur la table ? pas plutôt sur la session ?

Vous pensez qu'il y a un moyen que ce verrouillage provienne d'un hotstandby et/ou du mécanisme de réplication ?

Non, la table temporaire n'est pas envoyée aux secondaires. Plus exactement, son contenu n'est pas répliqué.

Est-ce que un curseur non fermé pourrait laisser traîner des locks et empêcher un DROP par exemple ?

Oui, bien sûr. Un curseur, c'est la lecture d'un objet. Donc il y a un verrou empêchant la suppression de cet objet ou sa redéfinition.

---

Guillaume.

herve.lefebvre

Membre

Re : Access*Lock sur table temporaire

Bon alors en fait après avoir commencé à récupérer les logs du client, il semble que la table temporaire bloquée n'est finalement pas une table temporaire

On est finalement dans un problème très classique avec des subqueries codées avec les pieds, qui prennent une plombe à s'exécuter et qui verrouillent une table dont une autre session a besoin. Désolé du dérangement...

Dernière modification par herve.lefebvre (26/07/2016 09:40:03)