Come recuperare lo spazio occupato da un indice parzialmente costruito e interrotto da un'interruzione di corrente

Sto eseguendo Postgres (Postgis) 9.4.2 su un Mac (10.10.4).

Ho un paio di grandi tavoli (diversi TB).

Durante un indice basato su uno di essi che dura circa una settimana, ho visto lo spazio disponibile in HD diminuire come ti aspetteresti fino al punto in cui l'indice sarebbe finito quando un'interruzione di corrente è durata più a lungo rispetto all'unità batteria e al sistema andato giù. Avevo i buffer disattivati ​​e fillfactor=100durante la compilazione poiché è un'origine dati statica. Al riavvio, lo spazio disponibile rimasto sull'unità è esattamente dove si trovava quasi alla fine della generazione dell'indice. L'analisi del vuoto non libera lo spazio.

Ho provato a far cadere il tavolo e re-ingerire, e questo non ha lasciato spazio. Ora sono in un posto dove non ho abbastanza spazio per costruire l'indice.

I file generati durante la generazione dell'indice sono bloccati in alcuni limbo in cui non possono essere rimossi dal sistema a causa del modo in cui la macchina è caduta durante l'interruzione di corrente?

Quando guardo le dimensioni della tabella + gli indici nel db (che è l'unico dato su quell'unità ) si sommano a circa 6 TB . L'unità ha 8 TB e rimangono meno di 500 GB sull'unità, quindi sembra che ci siano circa 1,5 TB persi da qualche parte che è circa la dimensione che l'indice sarebbe stato.

Qualche idea?

Normalmente ci aspetteremmo che al riavvio di postgres il processo di recupero da crash avrebbe rimosso i file relativi a un indice di rollback dalla directory dei dati.

Supponiamo che non abbia funzionato, o almeno che debba essere controllato manualmente.

L'elenco dei file che dovrebbero essere nel datadir può essere stabilito con una query come questa:

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

reltablespace=0è per il tablespace predefinito. Se l'indice problematico è stato creato in un tablespace non predefinito, questo 0deve essere sostituito dal suo OID in pg_tablespace.

i, r, t, S, m relkindcorrispondono rispettivamente a indici, tabelle, spazio toast, sequenze, viste materializzate. Tutti questi oggetti hanno i loro dati in file i cui nomi corrispondono pg_relation_filenode(oid).

Sul disco, i file di dati sono sotto $PGDATA/base/oid/dove si oidtrova oidil database ottenuto da select oid,datname from pg_database. Se non stiamo parlando del tablespace predefinito, baseviene PG_version_somelabelinvece sostituito da .

Elenca e ordina i file corrispondenti a relfilenodes in quella directory:

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

(che in realtà mantiene solo il primo segmento per le relazioni che sono più grandi di 1 GB. Se ci sono segmenti persistenti non collegati a nulla, dovrebbero essere considerati separatamente)

e diff quel file con il risultato della query sopra.

Se ci sono file di dati persistenti che non corrispondono a nessun oggetto di cui il db sia a conoscenza, dovrebbero apparire in quella diff.