Hallo,
Ich habe nicht soviel Ahnung(speziell unter Windows) was von dieser Log-Meldung zu halten ist.
Du hast ein paar Optionen:
- schreib mal auf der general-ML (oder bugs-ML?) was, am Besten genauso ausführlich, wie in deiner 1. Mail, und guckst mal was dabei rauskommt.
Die Entwickler lesen dort mit und haben eher eine Idee welcher Codepfad zu solch einem Fehler führt.
- du solltest auf jeden Fall vorher auf 8.4.7 aktualisieren und prüfen, ob der Fehler dann verschwindet. Man sollte nicht Bugs jagen, die schon behoben sind.
- Am besten du gehst direkt auf 9.0.3 und zwar die x64-Variante. Dann hast du erst Mal Ruhe vor den Begrenzungen eines 32-Bit Prozesses
Was ich immer noch nicht verstehe ist, in welchem Zusammenhang diese Logmeldung auftaucht.
Du solltest z.B. das Logging beim autovacuum erhöhen.
Auf deinem Screenshot ist ein pgsql-Prozess zu sehen, der über 600 MB an privatem Speicher benutzt, was macht der ?
soviel in kürze
Freundliche Grüße
hkocam
Nur zur Information: Ich habe den DB-Server diese Nacht neu gestartet, wobei ich das shared_buffers noch auf 128MB gesetzt habe (vorher 256MB). Seit dem Zeitpunkt bekommen ich keinen Fehler-Eintrag mehr im Log. Was ich jetzt nicht sagen kann, ist, ob es der Neustart war, oder das heruntersetzen von shared_buffers oder beides. Ich werde beim nächsten Neustart den Wert wieder zurücksetzen, um dies herauszufinden. Das wird jedoch nicht so bald geschehen. Zudem werden ich in den nächsten 4 Wochen auf Version 9 umstellen. Bin ja gespannt, was dies für die Performance bedeutet.
Fazit: Im zweifelsfall DB-Server erste mal neu starten und ab Version 8.4 auf Windows, shared_buffers klein halten.
Falls ich noch was zusätzliches herausfinde, werde ich dies gerne hier posten. Danke für eure Mithilfe!
Hier noch einen Hinweis von Tom Lane erhalten über die mailinglist:
Right offhand this looks like a corrupt-data problem, ie, trashed length word in some variable-length value. Autovacuum isn't particularly at fault, it just happens to be trying to examine a value that you haven't read lately in regular use of the database. I'd suggest seeing whether pg_dump doesn't find the problem too; if so you'll need to start doing data recovery.
Links: Tobias Bauer - IT- und Funkdienstleistungen - Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen - Funkforum
Lesezeichen