Comment récupérer de l'espace occupé par un index partiellement construit et terminé par une panne de courant

J'utilise postgres (postgis) 9.4.2 sur un mac (10.10.4).

J'ai quelques grandes tables (plusieurs To).

Au cours de la construction d'un index sur l'un d'entre eux, qui prend environ une semaine, j'ai vu l'espace HD disponible chuter comme vous vous attendez à presque le point où l'index serait terminé lorsqu'une panne de courant a duré plus longtemps que l'unité de batterie et le système est descendu. J'ai eu des tampons hors tension, et fillfactor=100pendant la construction car c'est une source de données statique. Au redémarrage, l'espace disponible restant sur le lecteur est exactement là où il se trouvait à la fin de la génération de l'index. L'analyse sous vide ne libère pas l'espace.

J'ai essayé de laisser tomber la table et de ré-ingérer, et cela n'a pas laissé de place. Maintenant, je suis à un endroit où je n'ai pas assez d'espace pour construire l'index.

Les fichiers générés lors de la construction de l'index sont-ils coincés dans des limbes où ils ne peuvent pas être supprimés par le système en raison de la panne de la machine pendant la panne de courant?

Quand je regarde les tailles de table + les index dans la base de données (qui sont les seules données sur ce lecteur), ils totalisent environ 6 To . Le disque est de 8 To , et il reste moins de 500 Go sur le disque, il semble donc qu'il y ait environ 1,5 To perdu quelque part, ce qui correspond à la taille de cet index.

Des idées?

Normalement, nous nous attendions à ce que lorsque postgres soit redémarré, le processus de récupération après incident ait supprimé les fichiers liés à un index restauré du répertoire de données.

Supposons que cela ne fonctionne pas, ou du moins qu'il doit être vérifié manuellement.

La liste des fichiers qui devraient être dans le datadir peut être établie avec une requête comme celle-ci:

select pg_relation_filenode(oid)
   from pg_class
  where relkind in ('i','r','t','S','m')
    and reltablespace=0
  order by 1;

reltablespace=0est pour le tablespace par défaut. Si l'index problématique a été créé dans un espace de table non par défaut, il 0doit être remplacé par son OID dans pg_tablespace.

i, r, t, S, m in relkindcorrespondent respectivement aux index, tables, toasts, séquences, vues matérialisées. Tous ces objets ont leurs données dans des fichiers dont les noms correspondent pg_relation_filenode(oid).

Sur disque, les fichiers de données sont en dessous $PGDATA/base/oid/où se oidtrouve oidla base de données obtenue par select oid,datname from pg_database. Si nous ne parlons pas du tablespace par défaut, baseest remplacé par à la PG_version_somelabelplace.

Répertoriez et triez les fichiers correspondant aux relfilenodes dans ce répertoire:

ls | grep -E '^[0-9]+$' | sort -n > /tmp/list-of-relations.txt

(qui ne conserve en fait que le premier segment pour les relations supérieures à 1 Go. S'il existe des segments persistants qui ne sont attachés à rien, ils doivent être considérés séparément)

et diff ce fichier avec le résultat de la requête ci-dessus.

S'il existe des fichiers de données persistants qui ne correspondent à aucun objet connu de la base de données, ils doivent apparaître dans cette différence.