Vous n'êtes pas identifié(e).
Pages : 1
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
Hors ligne
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/
Hors ligne
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==';
Hors ligne
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
Hors ligne
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 * * * * *
Hors ligne
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.
Hors ligne
Pages : 1
