PostgreSQL: spazio su disco non rilasciato dopo TRUNCATE

Ho TRUNCATEun enorme tavolo (~ 120Gb) chiamato files:

TRUNCATE files;
VACUUM FULL files;

La dimensione della tabella è 0, ma non è stato rilasciato spazio su disco. Qualche idea su come recuperare il mio spazio su disco perso?

AGGIORNAMENTO: Lo spazio su disco è stato rilasciato dopo ~ 12 ore, senza alcuna azione da parte mia. Uso il server Ubuntu 8.04.

postgresql truncate disk-space

— Adam Matan
fonte

Stavo per suggerire di "svuotarlo!", Ma considerando che l'hai appena fatto, ti consiglio di portarlo su uno dei pg-hacker o degli elenchi di pg performance (e di ricollegarti al thread o rispondere una volta che hai uno).

— Denis de Bernardy,

Questo link ( postgresql.1045698.n5.nabble.com/… ) ti dà qualche consiglio? Forse c'è ancora qualcosa che accede al tavolo o simile.

— DrColossos,

@DrColossos: ho letto un commento nella fonte (un commento che non riesco a trovare in questo momento) in cui PostgreSQL ha notificato tutte le connessioni che stava per avvenire un troncamento e ha bloccato le risorse necessarie. (Ce ne sono diversi, tra cui la tabella stessa, gli indici, le sequenze e le tabelle dei toast.) Sono abbastanza sicuro di aver trovato il commento in precedenza tracciando tramite ExecuteTruncate (), ma non ne sono sicuro al 100%.

— Mike Sherrill "Cat Recall",

Secondo i commenti nella fonte , truncatecrea un nuovo file di archiviazione vuoto ed elimina il vecchio file di archiviazione al momento del commit. (I documenti suggeriscono che "file di archiviazione" è solo un file per quanto riguarda il sistema operativo, ma potrei essere frainteso la terminologia.)

Creare un nuovo file di archiviazione vuoto per la relazione e assegnarlo come valore relfilenode. Il vecchio file di archiviazione è programmato per l'eliminazione al commit.

Dal momento che sembra cancellare un file, posso immaginare alcuni casi in cui il sistema operativo sottostante potrebbe non liberare immediatamente quello spazio. Immagino che in alcuni casi il file di archiviazione potrebbe finire nel Cestino sotto Windows, ad esempio. Ma nel mio caso, troncare una tabella in PostgreSQL 9. qualcosa ha immediatamente aumentato lo spazio libero in Windows.

Il troncamento viene inoltre registrato nel registro WAL. Non so quanto effetto potrebbe avere.

— Mike Sherrill 'Cat Recall'
fonte

È concepibile che un altro processo di back-end abbia ancora un descrittore di file per il file aperto. Se ciò dovesse accadere di nuovo, proverei a terminare tutti gli altri processi di back-end, solo per vedere se fa la differenza.

— Peter Eisentraut,

Sono abbastanza sicuro di aver letto che ExecuteTruncate () dovrebbe assicurarsi che ciò non accada. Tutto parte del blocco delle risorse necessarie per eliminare eventualmente il vecchio file di archiviazione. Ma non so dove l'ho trovato nella fonte. Sto solo navigando online; è facile perdersi in quel modo.

— Mike Sherrill "Cat Recall",