PostgreSQL: espaço em disco não liberado após TRUNCATE


12

Eu tenho TRUNCATEuma tabela enorme (~ 120Gb) chamada files:

TRUNCATE files;
VACUUM FULL files;

O tamanho da tabela é 0, mas nenhum espaço em disco foi liberado. Alguma idéia de como recuperar meu espaço em disco perdido?

ATUALIZAÇÃO: O espaço em disco foi liberado após ~ 12 horas, sem nenhuma ação do meu lado. Eu uso o servidor Ubuntu 8.04.


Eu estava prestes a sugerir "aspirar!", Mas, considerando que você acabou de fazer, eu recomendaria levar isso para as listas pg-hackers ou pg-performance (e vincular ao tópico ou responder assim que você tiver 1).
— Denis de Bernardy

Este link ( postgresql.1045698.n5.nabble.com/… ) fornece algum conselho para você? Talvez ainda exista algo acessando a tabela ou similar.
— DrColossos

@DrColossos: li um comentário na fonte (um comentário que não consigo encontrar no momento) que dizia que o PostgreSQL notificava todas as conexões que um truncado estava prestes a ocorrer e bloqueava os recursos necessários. (Existem várias, incluindo a própria tabela, índices, sequências e tabelas de brinde.) Tenho certeza de que encontrei o comentário anteriormente, percorrendo ExecuteTruncate (), mas não sou 100% positivo sobre isso.
— Mike Sherrill 'Cat Recall'

Respostas:


12

De acordo com os comentários na fonte , truncatecria um novo arquivo de armazenamento vazio e exclui o antigo arquivo de armazenamento no momento da confirmação. (Os documentos sugerem "arquivo de armazenamento" é apenas um arquivo no que diz respeito ao sistema operacional, mas talvez eu esteja entendendo mal a terminologia.)

Crie um novo arquivo de armazenamento vazio para a relação e atribua-o como o valor relfilenode. O arquivo de armazenamento antigo está agendado para exclusão na confirmação.

Como parece estar excluindo um arquivo, posso imaginar alguns casos em que o sistema operacional subjacente pode não liberar imediatamente esse espaço. Eu imagino que, em alguns casos, o arquivo de armazenamento possa acabar na Lixeira no Windows, por exemplo. Mas, no meu caso, truncar uma tabela no PostgreSQL 9.algo aumentou imediatamente o espaço livre no Windows.

O truncamento também é registrado no log do WAL. Não sei quanto efeito isso pode ter.


2
É concebível que outro processo de back-end ainda tenha um descritor de arquivo para o arquivo aberto. Se isso acontecer novamente, tentarei encerrar todos os outros processos de back-end, apenas para ver se isso faz diferença.
— Peter Eisentraut

Tenho certeza de que li que ExecuteTruncate () deve garantir que isso não aconteça. Tudo parte do bloqueio dos recursos necessários para, eventualmente, excluir o arquivo de armazenamento antigo. Mas não sei onde encontrei isso na fonte. Estou apenas navegando on-line; é fácil se perder dessa maneira.
— Mike Sherrill 'Cat Recall'
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.