Vous n'êtes pas identifié(e).
Pages : 1
Ok, merci de votre aide en tout cas et si j'obtiens des infos, je publierai à la suite de ce post.
Démarrage en mode autonome puis REINDEX SYSTEM postgres sur la base système.
--> Aucune erreur à la réindexation.
--> Par contre la commande DROP INDEX flows_a37_h14_m30_in_inf; ne fonctionne toujours pas (could not open relation with OID 9964489).
ok, merci, je tente la manip et reviens vers le forum.
Il y avait un index correct mais je l'ai droppé pour tester. Et il y avait 2 index incorrects.
Aucune ligne.
Voici les requêtes.
flows=# select oid from pg_class where relname='flows_a37_h14_m30';
oid
----------
29619941
flows=# update pg_index set indrelid=29619941 where indexrelid=9964786;
UPDATE 1Ensuite, je demande l'affichage des propriétés des la table avec
flows=# \d flows_a37_h14_m30et il ne sort toujours pas l'index en question.
Pourtant, la table est bien là ! Il arrive d'ailleurs à supprimer d'autres index sur la même table.
Une particularité est que les index sont tous droppés dans la même query :
DROP INDEX flows_a37_h14_m30_timestamp;DROP INDEX flows_a37_h14_m30_in_inf;DROP INDEX flows_a37_h14_m30_out_inf;Une autre particularité est que cette table est en fait une partition et au moment où on essaye de dropper ses index (pour accélérer des COPY), elle est encore connectée à la table mère. Serait-ce plus sûr de la déconnecter avant ?
En fait l'objet référencé par l'oid indiqué semble ne pas exister. Pour synthétiser le pb, j'ai utilisé un autre index (j'avais perdu le nom du premier) et voici la suite de requêtes :
flows=# DROP INDEX flows_a37_h14_m30_in_inf;
ERROR: could not open relation with OID 9964489
flows=# CREATE INDEX flows_a37_h14_m30_in_inf ON flows_a37_h14_m30 USING btree(in_inf);
ERROR: relation "flows_a37_h14_m30_in_inf" already exists
flows=# select * from pg_class where oid=9964489;
(0 rows)
flows=# select * from pg_index where indexrelid=9964489;
(0 rows)
flows=# select spclocation, relfilenode from pg_class, pg_tablespace where reltablespace=pg_tablespace.oid and pg_class.oid=9964489;
(0 rows)
flows=# select relfilenode from pg_class where oid=9964489;
(0 rows)
flows=# select relfilenode from pg_class where oid=9964489;
(0 rows)Mais si je cherche l'index par son nom, là je trouve :
flows=# select oid,* from pg_class where relname='flows_a37_h14_m30_in_inf';
oid | relname | relnamespace | reltype | relowner | relam | relfilenode | reltablespace | relpages | reltuples | reltoastrelid | reltoastidxid | relhasindex | relisshared | relkind | relnatts | relchecks | reltriggers | relukeys | relfkeys | relrefs | relhasoids | relhaspkey | relhasrules | relhassubclass | relfrozenxid | relacl | reloptions
---------+--------------------------+--------------+---------+----------+-------+-------------+---------------+----------+-----------+---------------+---------------+-------------+-------------+---------+----------+-----------+-------------+----------+----------+---------+------------+------------+-------------+----------------+--------------+--------+------------
9964786 | flows_a37_h14_m30_in_inf | 2200 | 0 | 10 | 403 | 9964786 | 0 | 2 | 356 | 0 | 0 | f | f | i | 1 | 0 | 0 | 0 | 0 | 0 | f | f | f | f | 0 | |
(1 row)Et on retrouve l'OID du début avec
flows=# select * from pg_index where indexrelid=9964786;
indexrelid | indrelid | indnatts | indisunique | indisprimary | indisclustered | indisvalid | indcheckxmin | indisready | indkey | indclass | indoption | indexprs | indpred
------------+----------+----------+-------------+--------------+----------------+------------+--------------+------------+--------+----------+-----------+----------+---------
9964786 | 9964489 | 1 | f | f | f | t | f | t | 14 | 1978 | 0 | |
(1 row)Revoilà le 9964489 qu'il n'arrive pas à ouvrir. A quoi est-ce que ça correspond ?
Sylvain
Aucune réponse à la requête : le fichier semble ne pas exister.
Merci de votre réponse.
Il s'agit de Postgresql 8.3.3
Quant à des problèmes fichiers, le serveur est totalement dédié à une seule tâche d'alimentation de la base via un robot Java qui ne manipule des fichiers que dans un seul dossier. Par contre, il y a quelques mois, on avait des pbs de perfs : on avait toutes les tables dans le tablespace par défaut ... et on avait atteint les limites systèmes en terme de nb de fichiers dans un seul dossier. On a alors décidé de mettre en place une politique de tablespace et il y a eu une migration massive des données et donc un déplacement par Postgresql des ses fichiers de stockage. Peut-être est-ce à cette occasion que certains fichiers ont été endommagés ?
Sylvain
Bonjour,
Sur une base de prod avec beaucoup de tables (34806) et d'index (133985). J'ai repéré quelques défauts d'intégrités et je voudrais savoir s'il existe des méthodes pour réparer.
Considérant une table normalement avec 3 index (nomtable_i1, nomtable_i2 et nomtable_i3), j'ai un seul des 3 index qui est correct : je peux le dropper, le re-créer, ...
Si je tente de dropper les autres, j'obtiens une erreur : ERROR : could not open relation with OID 9050310.
Si je tente de créer un index avec le même nom, j'obtiens : ERROR : relation "nomtable_i2" already exists
En fouillant dans les tables systèmes, j'ai trouvé que les index en erreur existent bien dans pg_class mais leur lien avec la table mère n'est pas dans pg_index. Or je ne peux pas agir sur les tables système : trop dangereux.
J'ai tenté : REINDEX TABLE ... ou REINDEX INDEX ... ou VACUUM table mais rien n'y fait.
Quelqu'un connait-il une méthode adequat pour résoudre ce problème ??
Merci de votre aide :-)
Sylvain Caillet
Pages : 1