Discussion :

[cocoyot]

Bonjour,
je travaille avec postgresql 8.3 sur debian.
Ma base est utilisée dans le cadre d'une application JEE au travers d'Hibernate (JBoss 4.2).
Mon problème à l'origine était que je n'arrivais pas à ajouter une colonne dans une table (la requête ALTER TABLE ne rendait pas la main comme bloquée sur un point critique.
Je me suis donc décidée à recréer une base vide en y réinjectant les données de la première.
La première n'est maintenant plus du tout utilisée mais il m'est impossible de la supprimer dropdb me renvoit une erreur comme quoi elle est en cours d'utilisation.
Une idée, une piste ?

[estofilo]

Ne serais-tu pas connectée à la base que tu veux supprimer? Si c'est le cas, il faut se connecter à une autre base, par exemple celle nommée postgres.

[cocoyot]

Et bien non. j'essaie avec la commande dropdb sonc je ne suis connectée à aucune base. J'ai bien vérifié que je n'ai pas d'appli connectée. J'ai même arrêté et redémarré le serveur postgresql avant de lancer ma commande dropdb. Rien à faire. J'ai pensé à un process autovacuum, je l'ai donc désactivé.

[estofilo]

Sinon on peut voir ce qui est connecté à une base avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select * from pg_stat_activity where datname='nom de la base'

[cocoyot]

Oui je l'avais déjà fait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
aipa2=> select * from pg_stat_activity where datname ='aipa';
 datid | datname | procpid | usesysid | usename | current_query | waiting | xact_start | query_start | backend_start | client_addr | client_port 
-------+---------+---------+----------+---------+---------------+---------+------------+-------------+---------------+-------------+-------------
(0 lignes)

J'y connais rien mais j'aurais pas des fichiers temporaires à effacer, il ya peut-être un fichier lock quelque part ?
Ou sinon, je peux peut-être supprimer la base en supprimant les fichiers data, mais comment le faire proprement ?

[estofilo]

Non il faut vraiment faire passer le drop database sans supprimer directement des fichiers.
Une autre idée:
1- en SQL, loggé en superutilisateur, faire ALTER DATABASE aipa connection limit=0;
2- arrêter et redémarrer l'instance postgres
3- contrôler le résultat de select * from pg_stat_activity (sur toutes les bases cette fois-ci) ainsi que select * from pg_database
4- drop database aipa;

S'il y a encore un message d'erreur, le copier dans ce fil de discussion.

[cocoyot]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
postgres=# select * from pg_stat_activity;
 datid | datname  | procpid | usesysid | usename  |          current_query          | waiting |          xact_start           |          query_start          |         backend_start         | client_addr | client_port 
-------+----------+---------+----------+----------+---------------------------------+---------+-------------------------------+-------------------------------+-------------------------------+-------------+-------------
 11511 | postgres |    7515 |       10 | postgres | select * from pg_stat_activity; | f       | 2011-03-24 14:25:48.538329+01 | 2011-03-24 14:25:48.538329+01 | 2011-03-24 14:25:12.759171+01 |             |          -1
(1 ligne)
 
postgres=# select * from pg_database ;
  datname  | datdba | encoding | datistemplate | datallowconn | datconnlimit | datlastsysoid | datfrozenxid | dattablespace | datconfig |               datacl                
-----------+--------+----------+---------------+--------------+--------------+---------------+--------------+---------------+-----------+-------------------------------------
 template1 |     10 |        6 | t             | t            |           -1 |         11510 |          379 |          1663 |           | {=c/postgres,postgres=CTc/postgres}
 template0 |     10 |        6 | t             | f            |           -1 |         11510 |          379 |          1663 |           | {=c/postgres,postgres=CTc/postgres}
 postgres  |     10 |        6 | f             | t            |           -1 |         11510 |          379 |          1663 |           | 
 aipa2     |  16384 |        6 | f             | t            |           -1 |         11510 |          379 |          1663 |           | 
 aipa      |  16384 |        6 | f             | t            |            0 |         11510 |          379 |          1663 |           | 
(5 lignes)
 
postgres=# drop DATABASE aipa;
ERREUR:  la base de données « aipa » est en cours d'utilisation par d'autres utilisateurs
postgres=#

[estofilo]

OK... (grattage de tête). Il est possible alors qu'il y ait des transactions préparées sur cette base qui empêche le DROP. Ce genre de chose résiste au redémarrage du serveur.
La commande suivante devrait le dire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select * from pg_prepared_xacts;

[cocoyot]

Ah ! Je crois qu'on tient le bon bout! Je fais un delete là dessus ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
postgres=# select * from pg_prepared_xacts;
 transaction |                                             gid                                              |           prepared            | owner | database 
-------------+----------------------------------------------------------------------------------------------+-------------------------------+-------+----------
       50564 | 131075_MS0tNTNlZmU1ZjM6YWRkMzo0Y2Y0YzhkZjo5ZTdjYzg=_LTUzZWZlNWYzOmFkZDM6NGNmNGM4ZGY6OWU3Y2Nk | 1915-01-02 04:04:51.879795+00 | aipa  | aipa
(1 ligne)

[estofilo]

Il faudrait maintenant en étant connecté à la base en question, faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ROLLBACK PREPARED '131075_MS0tNTNlZmU1ZjM6YWRkMzo0Y2Y0YzhkZjo5ZTdjYzg=_LTUzZWZlNWYzOmFkZDM6NGNmNGM4ZGY6OWU3Y2Nk';

[cocoyot]

Yes ! Je vais maintenant regarder de plus près dans la doc cette histoire de transaction préparée, ça doit être hibernate qui les crée.
Merci beaucoup !