REINDEX

Description

REINDEX reconstruit un index basé sur les données stockées dans la table, remplaçant l'ancienne copie de l'index. Il y a deux raisons principales pour utiliser REINDEX :

• Un index a été corrompu et ne contient plus de données valides. Bien qu'en théorie, ceci ne devrait jamais arriver, en pratique, les index peuvent se corrompre à cause de bogues dans le logiciel ou d'échecs matériels. REINDEX fournit une méthode de récupération.

• L'index en question contient beaucoup de pages d'index mortes qui ne sont pas réclamés. Ceci peut arriver avec des index B-tree dans PostgreSQL sous certains modèles d'accès. REINDEX fournit un moyen de réduire la consommation d'espace de l'index en écrivant une nouvelle version de l'index sans les pages mortes. Voir Section 21.2 pour plus d'informations.

Paramètres

Notes

Si vous suspectez une corruption d'un index sur une table utilisateur, vous pouvez simplement reconstruire cet index, ou tous les index de la table, en utilisant REINDEX INDEX ou REINDEX TABLE. Une autre approche pour gérer un index corrompu de table utilisateur est de simplement le supprimer et de le recréer. Ceci pourrait en fait être préférable si vous souhaitez maintenir un certain état d'opérations de base sur la table pendant ce temps. REINDEX acquiert le verrou exclusif sur la table alors que CREATE INDEX verrouille seulement l'écriture et non pas les lectures de la table.

Les choses sont plus difficiles si vous avez besoin de récupérer de la corruption d'un index sur une table système. Dans ce cas, il est important pour le système de ne pas avoir utilisé lui-même un des index suspects. (En fait, dans ce type de scénario, vous pourriez trouver que les processus serveur s'arrêtent brutalement immédiatement au lancement, à cause du besoin des index corrompus.) Pour récupérer proprement, le serveur doit être lancé avec l'option -P, qui l'empêche d'utiliser les recherches de catalogues système.

Une façon de faire ceci est d'arrêter le postmaster et de lancer le serveur PostgreSQL en mode autonome avec l'option -P placée sur la ligne de commande. Ensuite, REINDEX DATABASE, REINDEX TABLE ou REINDEX INDEX peuvent être lancés suivant ce que vous souhaitez reconstruire. En cas de doute, utilisez REINDEX DATABASE pour sélectionner la reconstruction de tous les index système dans la base de données. Enfin, quittez la session autonome du serveur et relancez le serveur habituel. Voir la page de référence de postgres pour plus d'informations sur l'interaction avec l'interface du serveur autonome.

Autrement, une session standard du serveur peut être lancée avec -P inclus dans les options de la ligne de commande. La méthode pour ce faire varie entre les clients mais dans tous les clients basés sur libpq, il est possible de configurer la variable d'environnement PGOPTIONS à -P avant de lancer le client. Notez que, bien que cette méthode ne réclamait pas le verrouillage des autres clients, il pourrait être conseillé d'empêcher les autres utilisateurs, il pourrait toujours être conseillé d'empêcher les autres utilisateurs de se connecter à la base de données endommagée jusqu'à la fin des réparations.

Si une corruption est suspectée dans les index de tout catalogue système partagée (pg_database, pg_group ou pg_shadow), alors un serveur autonome doit être utilisé pour le réparer. REINDEX ne traitera pas les catalogues partagées dans le mode multiutilisateur.

Pour tous les index sauf les catalogues système partagées, REINDEX est protégé contre les arrêts brutaux et comprend les transactions. REINDEX n'est pas protégé pour les index partagés, ce qui explique pourquoi ce cas est désactivé pendant les opérations normales. Si un échec survient lors de la réindexation d'un de ces catalogues dans le mode autonome, il ne sera pas possible de relancer le serveur régulier jusqu'à ce que le problème soit rectifié. (Le symptome typique d'un index partagé reconstruit partiellement est << index n'est pas un btree >> errors.)

Avant PostgreSQL 7.4, REINDEX TABLE ne traitait pas automatiquement les tables TOAST et, du coup, elles devaient être réindexées par des commandes séparées. C'est toujours possible mais redondant.

Exemples

Recrée les index sur la table ma_table :

REINDEX TABLE ma_table;

Reconstruit un index simple :

REINDEX INDEX my_index;

Reconstruit tous les index système d'une base de données particulière sans croire qu'elles sont déjà valides :

$ export PGOPTIONS="-P"
$ psql broken_db
...
broken_db=> REINDEX DATABASE broken_db;
broken_db=> \q

Compatibilité

Il n'existe pas de commande REINDEX dans le standard SQL.