Forums PostgreSQL.fr

F.Chanson

Membre

BLocage Postgres 8.4.4

Bonjour, 

Postgres 8.4.4 se bloque sous psql et sous pgadmin lors de l’exécution de la  commande  suivante "alter table xxxxxxxxxxx  drop constraint FKE4E5D3E69E8C4A99 ;"
La contrainte existe , un index existe sur la  contrainte et  la table fait 200.000 enregistrements
Aucune info dans les Logs
La base est en  "archive_mode à true "
Cette commande est OK sur notre bd de développement 

voici la séquence passée
1) Arrêt postgres
2) Démarrage postgres
3) passage sous psql
4) alter table xxxxxxxxxxx  drop constraint FKE4E5D3E69E8C4A99 ;
Blocage postgres qui ne rend pas la main .....
5) ctrl-c  provoque l'abandon de commande et j'ai de nouveau la main sous psql

faut-il détruire l'index avant de détruire  la  contrainte ? ou ajouter  "l'option CASCADE ?

merci d'avance

rjuju

Administrateur

Re : BLocage Postgres 8.4.4

Bonjour.
Que donne la vue pg_stat_activity lors du drop constraint ? La requête est-elle bloquée ? (waiting = true)

---

Julien.
https://rjuju.github.io/

F.Chanson

Membre

Re : BLocage Postgres 8.4.4

Bonjour, le Pb a été fixe

la table pg_stat_activity lors du drop constraint precise que la transaction est en waiting = true

Après investigation , la table était locké par une transaction qui avait échoué lors d'un two-phase commit

Correction apportée => faire un rollback  manuel des transactions qui ont échouées.

> psql -p nnnnn -h xxxxxx-U dbadmin postgres
psql (8.4.1, server 8.4.4)
postgres=#  SELECT database, gid FROM pg_prepared_xacts;
    database    |                                           gid                                           

----------------+------------------------------------------------------------------------------------------

db1                 | 131075_MS0tN2RlZmY1YzU6Y2NhMDo0Y2QwMWZmNToxZjA2_LTdkZWZmNWM1OmNjYTA6NGNkMDFmZjU6MWYwZQ==

db1=# \connect  db1                 ;
db1=# ROLLBACK PREPARED  '131075_MS0tN2RlZmY1YzU6Y2NhMDo0Y2QwMWZmNToxZjA2_LTdkZWZmNWM1OmNjYTA6NGNkMDFmZjU6MWYwZQ==';

cedric

Membre

Re : BLocage Postgres 8.4.4

Bonjour, le Pb a été fixe

la table pg_stat_activity lors du drop constraint precise que la transaction est en waiting = true

Après investigation , la table était locké par une transaction qui avait échoué lors d'un two-phase commit

Je vous conseille très fortement de contrôler le 2PC: cela impacte les taches de maintenance et peut introduire beaucoup (trop) d'espace mort dans vos tables et index.

---

Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation

SQLpro

Membre

Re : BLocage Postgres 8.4.4

De toute façon et comme je l'ai indiqué dans cet article, le commit à deux phases ou Two Phase Comit (2PC) ne garantit pas l'acidité des transactions, contrairement à ce que je voit trop souvent écrit, y compris dans certains manuel de PG comme : http://wiki.postgresql.org/images/8/86/ … cation.pdf page 12...

A +

---

Frédéric Brouard, alias SQLpro,  ARCHITECTE DE DONNÉES,  Expert langage SQL
Le site sur les SGBD relationnel et langage SQL   : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * *  Enseignant CNAM PACA, ISEN Toulon,  CESI Aix en Provence  * * * * *

F.Chanson

Membre

Re : BLocage Postgres 8.4.4

Bonjour,

Après analyse (nagios) , il apparait que l'un des serveurs (machine virtuelle) qui héberge une de mes BDs  est tombé, ce qui a du causer le  pb lors du 2PC de de cette transaction qui impacte 4 BD postgres.  Sur l'autre cluster postgres sur un autre serveur qui héberge  les 3 autres Bds  RAS .

merci pour vos réponses.