PostgreSQL: Speicherplatz nach TRUNCATE nicht freigegeben

Ich habe TRUNCATEeine riesige (~ 120 GB) Tabelle mit dem Namen files:

TRUNCATE files;
VACUUM FULL files;

Die Tabellengröße ist 0, es wurde jedoch kein Speicherplatz freigegeben. Irgendwelche Ideen, wie ich meinen verlorenen Speicherplatz zurückerhalten kann?

UPDATE: Der Speicherplatz wurde nach ca. 12 Stunden ohne mein Zutun freigegeben. Ich benutze Ubuntu 8.04 Server.

postgresql truncate disk-space

— Adam Matan
quelle

Ich wollte "Vakuumieren!" Vorschlagen, aber wenn man bedenkt, dass Sie es gerade getan haben, würde ich empfehlen, dies entweder in die pg-Hacker- oder die pg-Performance-Liste zu übernehmen (und dann auf den Thread zurückzugreifen oder zu antworten, sobald Sie es haben einer).

— Denis de Bernardy

Gibt dieser Link ( postgresql.1045698.n5.nabble.com/… ) Ratschläge für Sie? Vielleicht greift noch etwas auf den Tisch oder ähnliches zu.

— DrColossos

@DrColossos: Ich habe einen Kommentar in der Quelle gelesen (einen Kommentar, den ich derzeit nicht finden kann), der besagt, dass PostgreSQL alle Verbindungen darüber informiert hat, dass eine Kürzung stattfinden soll, und die erforderlichen Ressourcen gesperrt hat. (Es gibt mehrere, einschließlich der Tabelle selbst, der Indizes, der Sequenzen und der Toast-Tabellen.) Ich bin mir ziemlich sicher, dass ich den Kommentar früher durch Durchlaufen von ExecuteTruncate () gefunden habe, aber ich bin nicht zu 100% davon überzeugt.

— Mike Sherrill 'Cat Recall'

Nach Kommentaren in der Quelle , truncateschafft eine neue, leere Speicherdatei und löscht die alte Speicherdatei zum Zeitpunkt begehen. (Die Dokumentation schlägt vor, dass "Speicherdatei" nur eine Datei ist, was das Betriebssystem betrifft, aber ich verstehe die Terminologie möglicherweise falsch.)

Erstellen Sie eine neue leere Speicherdatei für die Beziehung und weisen Sie sie als relfilenode-Wert zu. Die alte Speicherdatei soll beim Festschreiben gelöscht werden.

Da eine Datei scheinbar gelöscht wird, kann ich mir einige Fälle vorstellen, in denen das zugrunde liegende Betriebssystem diesen Speicherplatz möglicherweise nicht sofort freigibt. Ich stelle mir vor, dass die Speicherdatei in einigen Fällen zum Beispiel unter Windows im Papierkorb landet. Aber in meinem Fall hat das Abschneiden einer Tabelle unter PostgreSQL 9. unter Windows sofort den freien Speicherplatz erhöht.

Das Abschneiden wird auch im WAL-Protokoll aufgezeichnet. Ich weiß nicht, wie viel Wirkung das haben könnte.

— Mike Sherrill 'Cat Recall'
quelle

Es ist denkbar, dass ein anderer Backend-Prozess noch einen Dateideskriptor für die geöffnete Datei hat. In einem solchen Fall würde ich versuchen, alle anderen Backend-Prozesse zu beenden, um festzustellen, ob dies einen Unterschied macht.

— Peter Eisentraut

Ich bin mir ziemlich sicher, dass ich gelesen habe, dass ExecuteTruncate () sicherstellen soll, dass dies nicht passieren kann. Der gesamte Teil des Sperrens der Ressourcen, die zum endgültigen Löschen der alten Speicherdatei erforderlich sind. Aber ich weiß nicht, wo ich das in der Quelle gefunden habe. Ich surfe nur online; Auf diese Weise kann man sich leicht verirren.

— Mike Sherrill "Cat Recall"