Notes
Si vous suspectez la 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
.
Les choses sont plus difficiles si vous avez besoin de récupérer 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
constater que les processus serveur s'arrêtent brutalement au
lancement du service, en cause l'utilisation des index corrompus.)
Pour récupérer proprement, le serveur doit être lancé avec l'option
-P, qui inhibe l'utilisation des index pour
les recherches dans les catalogues système.
Une autre façon est d'arrêter le serveur et de relancer le serveur
PostgreSQL™ en mode simple
utilisateur avec l'option -P placée sur la
ligne de commande. Ensuite,
REINDEX
DATABASE
,
REINDEX
SYSTEM
,
REINDEX
TABLE
ou
REINDEX
INDEX
peuvent être lancés suivant ce que vous
souhaitez reconstruire. En cas de doute, utilisez la commande
REINDEX SYSTEM
pour
activer la reconstruction de tous les index système de la base de
données. Enfin, quittez la session simple utilisateur du serveur et
relancez le serveur en mode normal. Voir la page de référence de
postgres
(1) pour plus
d'informations sur l'interaction avec l'interface du serveur en
mode simple utilisateur.
Une session standard du serveur peut aussi être lancée avec
-P 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 verrouille pas les autres clients, il est
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 d'un des catalogues
système partagés (qui sont pg_authid, pg_auth_members, pg_database, pg_pltemplate, pg_shdepend, pg_shdescription et pg_tablespace), alors un serveur autonome doit
être utilisé pour le réparer.
REINDEX
ne traite pas les
catalogues partagés dans le mode multi-utilisateur.
Pour tous les index sauf les catalogues système partagés,
REINDEX
est protégé
contre les arrêts brutaux et utilise 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 n'est
pas possible de relancer le serveur en mode normal jusqu'à ce que
le problème soit rectifié (le symptôme typique d'un index partagé
reconstruit partiellement est une erreur « index n'est pas un btree »).
REINDEX
est similaire
à une suppression et à une nouvelle création de l'index, dans les
fait le contenu de l'index est complètement recréé. Néanmoins, les
considérations de verrouillage sont assez différentes.
REINDEX
verrouille les écritures
mais pas les lectures de la table mère de l'index. Il positionne
également un verrou exclusif sur l'index en cours de traitement, ce
qui bloque les lectures qui tentent de l'utiliser. Au contraire,
DROP INDEX
crée
temporairement un verrou exclusif sur la table parent, bloquant
ainsi écritures et lectures. Le
CREATE INDEX
qui suit verrouille
les écritures mais pas les lectures ; comme l'index n'existe pas,
aucune lecture ne peut être tentée, signifiant qu'il n'y a aucun
blocage et que les lectures sont probablement forcées de réaliser
des parcours séquentiels complets. Un autre point important est que
l'approche suppression/création invalide tous plans de requête en
cache utilisant cet index, problème que
REINDEX
ne connaît pas.
Ré-indexer un seul index ou une seule table requiert d'être le
propriétaire de cet index ou de cette table. Ré-indexer une base de
données requiert d'être le propriétaire de la base de données
(notez du coup que le propriétaire peut reconstruire les index de
tables possédées par d'autres utilisateurs). Bien sûr, les
superutilisateurs peuvent toujours tout ré-indexer.
Avant PostgreSQL™ 8.1,
REINDEX DATABASE
traitait seulement les index systèmes, pas tous les index comme on
pourrait le supposer d'après le nom. Ceci a été modifié pour
réduire le facteur de surprise. L'ancien comportement est
disponible en tant que
REINDEX
SYSTEM
.
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.