Unverwendete Dateien in DB Ordner - Werden in pg_class.relfilenode nicht gelistet

Hallo,

Ich habe folgendes Problem (Postgres 8.3)

Ich habe festgestellt, dass in meinem DB Ordner sich ein oder mehrere gr��ere Files ansammeln (10-50MB), welche in der pg_class.relfilenode nicht mehr gelistet werden. (Ich habe extra ein Programm geschrieben, dass die Files mit den DB-Eintr�gen vergleicht)

Da das Terminal, auf dem die Anwendung entwickelt wird, speicherm��ig sehr begrenzt ist, w�re f�r mich folgendes sehr interessant:

  1. K�nnen Dateien, die nicht mehr in pg_class.relfilenode gelistet werden, ohne Bedenken gel�scht werden (oder hat vielleicht postgres noch an einer anderen Stelle Referenzen auf die Files aus dem DB Ordner?)

Ich habe verschiedene Funktionen ausprobiert, um zu sehen, ob diese eine Auswirkung auf die Dateien haben:

  • VACUUM
  • VACUUM FULL
  • CHECKPOINT
  • ANALYZE

Die Dateien waren auch nach Ausf�hrung dieser Funktionen noch vorhanden.

Ich habe mir inzwischen schon ein Programm geschrieben, dass solche unverlinkte Dateien einfach l�scht (das scheint soweit auch zu funktionieren), da die Daten von Kunden jedoch sehr kritisch sind, m�chte ich noch einmal sicher gehen, ob diese auch wirklich nicht mehr irgendwo von postgres verwendet werden.

  1. Wie und wann k�nnen solche Dateien entstehen:

Die Anwendung, die ich entwicklte, l�uft auf einer Messstation. Dort kann es nat�rlich passieren, dass der Strom ausf�llt, oder auch der watchdog manchmal das Ger�t brutal neu startet. Mit postgres hatten wir dabei jedoch noch nie Probleme (kein korrupten Dateien, etc.). Um - wie gesagt - die Datenbank klein zu halten, werden auch regelm��ig Wartungsaufgaben ausgef�hrt, darunter unter anderem “VACUUM”, “VACUUM FULL”, “REINDEX” und “ANALYZE”

Ich habe jetzt versucht, die Datenbank manuell ein paar mal in verschiedenen Phasen zu killen, und zu schauen, ob solche unverlinkten Files entstehen, unter anderem auch w�hrend die obig angef�hrten Kommandos liefen, leider aber ohne Erfolg (ich konnte keine unverlinkte Datei �ber 0b - ich konnte nur beobachten, dass bei einem crash scheinbar 3 x 0b unverlinkte Dateien �brigbleiben, die dann aber beim n�chsten CHECKPOINT wieder verschwinden)

Jedenfalls m�chte ich gerne wissen, unter welchen Umst�nden solche unverlinkten Dateien > 0 byte im Datenbank-Ordner entstehen k�nnen? Hat jemand eine Idee? Ich vermute nat�rlich, dass es irgendwie mit Crashs zusammenh�ngen k�nnte, aber wenn ja, unter welchen Umst�nden? Kann das bei normalen Transaktionen passieren, bei Checkpoints, oder bei DB Verwaltungsma�nahmen?


Ich w�re wirklich sehr froh, wenn mir jemand hier weiterhelfen k�nnte.
Vielen Dank & lg
Flo

Das sollte eigentlich nicht passieren. Was Du tun kannst: vollständiges Backup (pg_dumpall), Cluster neu aufsetzen, Restore.

Einfach in relfilenodes guggen & löschen würde ich nicht wirklich empfehlen - was ist mit Dateien, die beim guggen noch nicht da waren, nun aber echten Content enthalten?

Andreas

@Andreas

Danke für den Tipp mit pg_dumpall & restore.

Ich entnehme aus deiner Antwort, dass meine Annahme, dass postgres alle verwendeten Dateien in relfilenode gelistet werden und es keine weiteren Referenzen auf die Dateien gibt, richtig war. Aber wie du richtig sagst, könnte es beim Löschen zu Race-Conditions kommen.

Jetzt stellt sich für mich natürlich die Frage unter welchen Bedingungen postgres neue Dateien anlegt. Das Datenschema meiner Datenbank ist fix, es werden keine Tabellen dynamisch angelegt, Indexe verändert, etc. Das einzige was passiert, ist das jedesmal beim Hochfahren der Datenbank Views neu angelegt werden.

Kann mir vielleicht jemand sagen, unter welchen Bedinungen postgres neue Dateien anlegt (oder wo genau finde ich die genaue Dokumentation dazu). Und gibt es nicht vielleicht ein Tool mit dem man den Inhalt von so verwaisten Dateien identifizieren kann?

Lg Florian

Neue Dateien werden u.a. angelegt, wenn es was zum TOASTen gibt (also sog. TOAST-Tabellen) und wenn Dateien größer als 1 GByte werden.

Ein Tool, was verwaiste Dateien sucht, ist mir nicht bekannt. Dazu sollte es auch nicht kommen. Falls Du das reproduzierbar belegen kannst, wäre eher ein Bugreport fällig.


Andreas