bt_index_check vérifie que sa cible, un index B-Tree, respecte un éventail de propriétés invariables. Exemple d'utilisation :

test=# SELECT bt_index_check(index => c.oid, heapallindexed => i.indisunique),
               c.relname,
               c.relpages
FROM pg_index i
JOIN pg_opclass op ON i.indclass[0] = op.oid
JOIN pg_am am ON op.opcmethod = am.oid
JOIN pg_class c ON i.indexrelid = c.oid
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE am.amname = 'btree' AND n.nspname = 'pg_catalog'
-- Ignore les tables temporaires, qui peuvent appartenir à d'autres sessions
AND c.relpersistence != 't'
-- La fonction peut renvoyer une erreur si cela est omis :
AND c.relkind = 'i' AND i.indisready AND i.indisvalid
ORDER BY c.relpages DESC LIMIT 10;
 bt_index_check |             relname             | relpages
----------------+---------------------------------+----------
                | pg_depend_reference_index       |       43
                | pg_depend_depender_index        |       40
                | pg_proc_proname_args_nsp_index  |       31
                | pg_description_o_c_o_index      |       21
                | pg_attribute_relid_attnam_index |       14
                | pg_proc_oid_index               |       10
                | pg_attribute_relid_attnum_index |        9
                | pg_amproc_fam_proc_index        |        5
                | pg_amop_opr_fam_index           |        5
                | pg_amop_fam_strat_index         |        5
(10 rows)
      

Cet exemple montre une session qui vérifie les 10 plus gros index du catalogue de la base de données « test ». La vérification de la présence des lignes de la table dans l'index est demandée pour le sous-ensemble des index uniques. Puisqu'aucune erreur n'est retournée, tous les index testés semblent être cohérents au niveau logique. Bien évidemment, cette requête pourrait être facilement modifiée pour appeler bt_index_check sur chacun des index présents dans la base de données pour lesquels la vérification est supportée.

bt_index_check acquiert un AccessShareLock sur l'index cible ainsi que sur la relation à laquelle il appartient. Ce niveau de verrouillage est le même que celui acquis sur les relations lors d'une simple requête SELECT. bt_index_check ne vérifie pas les propriétés invariantes qui englobent les relations enfant/parent, mais vérifiera la présence de toutes les lignes de la table et des lignes d'index à l'intérieur de l'index quand heapallindexed vaut true. Quand il faut lancer un test de recherche de corruption, de routine et pas trop lourd, sur un environnement de production, l'utilisation de bt_index_check offre généralement le meilleur compromis entre vérification minutieuse et impact limité sur les performances et la disponibilité de l'application.

bt_index_parent_check teste que sa cible, un index B-Tree, respecte un certain nombre de propriétés invariantes. En option, quand l'argument heapallindexed vaut true, la fonction vérifie la présence de toutes les lignes dans la table, et la présence de tous les liens dans la structure de l'index. Les vérifications réalisables par bt_index_parent_check sont un sur-ensemble des vérifications réalisées par bt_index_check. On peut voir bt_index_parent_check comme une version plus minutieuse de bt_index_check : contrairement à bt_index_check, bt_index_parent_check vérifie également les propriétés invariantes qui englobent les relations parent/enfant. bt_index_parent_check respecte la convention habituelle qui consiste à retourner une erreur si une incohérence ou tout autre problème est détecté.

Un verrou de type ShareLock est requis sur l'index ciblé par bt_index_parent_check (un ShareLock est également acquis sur la relation associée). Ces verrous empêchent des modifications concurrentes par des commandes INSERT, UPDATE et DELETE. Les verrous empêchent également la relation associée d'être traitée de manière concurrente par VACUUM, ainsi que toute autre commande d'administration. Il est à noter que cette fonction ne conserve les verrous uniquement que durant son exécution et non pas durant l'intégralité de la transaction.

La vérification supplémentaire qu'opère bt_index_parent_check est plus apte à détecter différents cas pathologiques. Ces cas peuvent impliquer une classe d'opérateur B-Tree implémentée de manière incorrecte utilisée pour l'index vérifié, ou, hypothétiquement, des bugs non encore découverts dans le code de la méthode d'accès associée à cet index B-Tree. Il est à noter que bt_index_parent_check ne peut pas être utilisé lorsque le mode Hot Standby est activé (c'est-à-dire, sur un serveur secondaire disponible en lecture seule), contrairement à bt_index_check.