Re: FEHLER: konnte auf den Status von Transaktion XY nicht zugreifen

Hallo,

ich hatte vor einiger Zeit über merkwürdieg Abstürze von Version 9.0
berichtet[1]. Ich konnte das Problem zwar nicht lösen, aber mit einem
Upgrade auf 9.1 war es dann verschwunden. Allerdings kann es auch sein,
daß es deswegen verschwunden war, weil ich sämtliche Datenbanken neu
erzeugt hatte (auf dem Server laufen zwei Datenbanken, eine ein Clone
der UDD (Ultimate Debian Database) und eine Datenbank im Rahmen eines
GSoC Projekts (teamanalysis of Debian teams). Beide lassen sich
automatisch generieren und daher ging es in dem neuen Server eben noch
mal von null los.

Seit einiger Zeit beobachte ich wieder in unregelmäßigen Abständen die
beschriebenen Abstürze. Ansonsten lief aber alles normal. Ich habe
keine Ahnung, ob das folgende Problem damit zusammenhängt, wollte aber
darauf hingewiesen haben.

Bei einer Abfrage per Python-Script an die UDD bekam ich heute folgende
Fehlermeldung:

Traceback (most recent call last):
File "./bug_close_history.py", line 101, in <module>
curs.execute(query)
psycopg2.OperationalError: FEHLER: konnte auf den Status von Transaktion 3301449728 nicht zugreifen
DETAIL: Konnte Datei »pg_clog/0C4C« nicht öffnen: Datei oder Verzeichnis nicht gefunden.
CONTEXT: SQL-Funktion »bug_closer_ids_of_pkggroup« Anweisung 1
SQL-Funktion »bug_closer_names_of_pkggroup« Anweisung 1

Die besagte Funktion existiert:

udd=# \df bug_closer_names_of_pkggroup
Liste der Funktionen
Schema | Name | Ergebnisdatentyp | Argumentdatentypen | Typ
--------+------------------------------+------------------+--------------------+--------
public | bug_closer_names_of_pkggroup | SETOF record | text, integer | normal
(1 Zeile)

das script lief kürzlich noch erfolgreich.

Ich habe heute postgresql-9.1 auf Version 9.1.2-4~bpo60+1 auf der
betreffenden Maschine aktualisiert. Ob es vorher noch ging, kann ich
nicht sagen.

Was kann ich tun?

Viele Grüße

Andreas.

[1] http://archives.postgresql.org/pgsql-de-allgemein/2011-08/msg00003.php

--
http://fam-tille.de

Andreas Tille <andreas(at)an3as(dot)eu> wrote:

> Hallo,
>
> ich hatte vor einiger Zeit über merkwürdieg Abstürze von Version 9.0
> berichtet[1]. Ich konnte das Problem zwar nicht lösen, aber mit einem
> Upgrade auf 9.1 war es dann verschwunden. Allerdings kann es auch sein,
> daß es deswegen verschwunden war, weil ich sämtliche Datenbanken neu
> erzeugt hatte (auf dem Server laufen zwei Datenbanken, eine ein Clone
> der UDD (Ultimate Debian Database) und eine Datenbank im Rahmen eines
> GSoC Projekts (teamanalysis of Debian teams). Beide lassen sich
> automatisch generieren und daher ging es in dem neuen Server eben noch
> mal von null los.
>
> Seit einiger Zeit beobachte ich wieder in unregelmäßigen Abständen die
> beschriebenen Abstürze. Ansonsten lief aber alles normal. Ich habe
> keine Ahnung, ob das folgende Problem damit zusammenhängt, wollte aber
> darauf hingewiesen haben.
>
> Bei einer Abfrage per Python-Script an die UDD bekam ich heute folgende
> Fehlermeldung:
>
> Traceback (most recent call last):
> File "./bug_close_history.py", line 101, in <module>
> curs.execute(query)
> psycopg2.OperationalError: FEHLER: konnte auf den Status von Transaktion 3301449728 nicht zugreifen
> DETAIL: Konnte Datei »pg_clog/0C4C« nicht öffnen: Datei oder Verzeichnis nicht gefunden.

Das ist das Problem.

Woran das liegt kann ich Dir nicht sagen, defekte Platte wäre eine
Option.

Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°

On Freitag, 27. Januar 2012, Andreas Tille wrote:

Hi,

> ich hatte vor einiger Zeit über merkwürdieg Abstürze von Version
> 9.0 berichtet
> DETAIL: Konnte Datei
> »pg_clog/0C4C« nicht öffnen: Datei oder Verzeichnis nicht
> gefunden.

Das hört sich alles sehr nach defekter Hardware an.
Ich würde mal RAM und Filesystem prüfen.

Gruß, Jens

Am 27.01.2012 15:24, schrieb Andreas Tille:
> Traceback (most recent call last):
> File "./bug_close_history.py", line 101, in<module>
> curs.execute(query)
> psycopg2.OperationalError: FEHLER: konnte auf den Status von Transaktion 3301449728 nicht zugreifen
> DETAIL: Konnte Datei »pg_clog/0C4C« nicht öffnen: Datei oder Verzeichnis nicht gefunden.
> CONTEXT: SQL-Funktion »bug_closer_ids_of_pkggroup« Anweisung 1
> SQL-Funktion »bug_closer_names_of_pkggroup« Anweisung 1
>
> Die besagte Funktion existiert:
>
> udd=# \df bug_closer_names_of_pkggroup
> Liste der Funktionen
> Schema | Name | Ergebnisdatentyp | Argumentdatentypen | Typ
> --------+------------------------------+------------------+--------------------+--------
> public | bug_closer_names_of_pkggroup | SETOF record | text, integer | normal
> (1 Zeile)
>
> das script lief kürzlich noch erfolgreich.
>
> Ich habe heute postgresql-9.1 auf Version 9.1.2-4~bpo60+1 auf der
> betreffenden Maschine aktualisiert. Ob es vorher noch ging, kann ich
> nicht sagen.
>
> Was kann ich tun?
Hallo Andreas,

es könnte sein, dass Du hier in ein bereits bekanntes Problem gelaufen
bist.
Um das allerdings genau zu analysieren, brauche ich mehrere Angaben von
Dir:

1. Welches Betriebssystem nutzt Du?
2. Wieviel Traffic ist auf der Datenbank?
3. Passieren die Abstürzen während Rush Hour?
4. Was sagt das PostgreSQL log vor den Abstürzen?

Viele Grüße,

Susanne

--
Dipl. Inf. Susanne Ebrecht - 2ndQuadrant
PostgreSQL Development, 24x7 Support, Training and Services
www.2ndQuadrant.com

--On 27. Januar 2012 18:00:33 +0100 Andreas Kretschmer
<akretschmer(at)spamfence(dot)net> wrote:

>> Traceback (most recent call last):
>> File "./bug_close_history.py", line 101, in <module>
>> curs.execute(query)
>> psycopg2.OperationalError: FEHLER: konnte auf den Status von Transaktion
>> 3301449728 nicht zugreifen DETAIL: Konnte Datei »pg_clog/0C4C« nicht
>> öffnen: Datei oder Verzeichnis nicht gefunden.
>
> Das ist das Problem.
>
> Woran das liegt kann ich Dir nicht sagen, defekte Platte wäre eine
> Option.

Das kann vielfältige Ursachen haben, von Problemen mit Filesystem bis hin
zu defekten Tupelheadern, verursacht bspw. durch defektes RAM. Alternativ
kämen noch Probleme mit pg_upgrade hinzu.

Eine Chance, dass diese Instanz in der Vergangenheit mit pg_upgrade "behandelt"
wurde?

--
Thanks

Bernd

Am 31. Januar 2012 16:20 schrieb Bernd Helmle <mailings(at)oopsware(dot)de>:

> --On 27. Januar 2012 18:00:33 +0100 Andreas Kretschmer
> <akretschmer(at)spamfence(dot)net> wrote:

[..]

>>> 3301449728 nicht zugreifen DETAIL:  Konnte Datei »pg_clog/0C4C« nicht
>>> öffnen: Datei oder Verzeichnis nicht gefunden.

[..]

> Das kann vielfältige Ursachen haben, von Problemen mit Filesystem bis hin
> zu defekten Tupelheadern, verursacht bspw. durch defektes RAM. Alternativ
> kämen noch Probleme mit pg_upgrade hinzu.

Ich understelle, dass auch Dateisystemebene-Backups mit laufendem
Server ohne pg_{start|stop}_backup oder ähnliche dazu führen können.

Nicolas

--
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?

--On 31. Januar 2012 17:41:54 +0100 Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com>
wrote:

> Ich understelle, dass auch Dateisystemebene-Backups mit laufendem
> Server ohne pg_{start|stop}_backup oder ähnliche dazu führen können.

Ja, das ist auch noch eine Möglichkeit. Allerdings treten dann meiner
Erfahrung nach noch deutlichere Symptome wie defekte Indexe oder TOAST-Pointer
auf. Gucken wir mal, was der OP dazu noch sagt...

--
Thanks

Bernd

On Fri, Jan 27, 2012 at 06:00:33PM +0100, Andreas Kretschmer wrote:
> > Bei einer Abfrage per Python-Script an die UDD bekam ich heute folgende
> > Fehlermeldung:
> >
> > Traceback (most recent call last):
> > File "./bug_close_history.py", line 101, in <module>
> > curs.execute(query)
> > psycopg2.OperationalError: FEHLER: konnte auf den Status von Transaktion 3301449728 nicht zugreifen
> > DETAIL: Konnte Datei »pg_clog/0C4C« nicht öffnen: Datei oder Verzeichnis nicht gefunden.
>
> Das ist das Problem.
>
> Woran das liegt kann ich Dir nicht sagen, defekte Platte wäre eine
> Option.

Was kann man noch versuchen? Ich habe jetzt beim Hoster die VM auf
einen anderen Node verschieben lassen. Seitdem beobachte ich zwar keine
Abstürze mehr (seit zwei Wochen), aber nun wieder folgendes:

Traceback (most recent call last):
File "/org/udd.debian.org/udd//udd.py", line 84, in <module>
exec "gatherer.%s()" % command
File "<string>", line 1, in <module>
File "/srv/udd.debian.org/udd/udd/src_and_pkg_gatherer.py", line 17, in run
self.src.run()
File "/srv/udd.debian.org/udd/udd/sources_gatherer.py", line 189, in run
cur.execute('ANALYZE %s' % utable)
psycopg2.OperationalError: FEHLER: konnte auf den Status von Transaktion 3279045664 nicht zugreifen
DETAIL: Konnte Datei »pg_clog/0C37« nicht öffnen: Datei oder Verzeichnis nicht gefunden.

Traceback (most recent call last):
File "/org/udd.debian.org/udd//udd.py", line 84, in <module>
exec "gatherer.%s()" % command
File "<string>", line 1, in <module>
File "/srv/udd.debian.org/udd/udd/src_and_pkg_gatherer.py", line 17, in run
self.src.run()
File "/srv/udd.debian.org/udd/udd/sources_gatherer.py", line 151, in run
% (utable, src_cfg['distribution'], src_cfg['release'], comp))
psycopg2.OperationalError: FEHLER: konnte auf den Status von Transaktion 3279045664 nicht zugreifen
DETAIL: Konnte Datei »pg_clog/0C37« nicht öffnen: Datei oder Verzeichnis nicht gefunden.

Traceback (most recent call last):
File "/org/udd.debian.org/udd//udd.py", line 84, in <module>
exec "gatherer.%s()" % command
File "<string>", line 1, in <module>
File "/srv/udd.debian.org/udd/udd/src_and_pkg_gatherer.py", line 17, in run
self.src.run()
File "/srv/udd.debian.org/udd/udd/sources_gatherer.py", line 151, in run
% (utable, src_cfg['distribution'], src_cfg['release'], comp))
psycopg2.OperationalError: FEHLER: konnte auf den Status von Transaktion 3279045664 nicht zugreifen
DETAIL: Konnte Datei »pg_clog/0C37« nicht öffnen: Datei oder Verzeichnis nicht gefunden.

...

Was sind das für Dateien ig pg_clog und warum können die verschwinden?

Viele Grüße

Andreas.

--
http://fam-tille.de

Andreas Tille schrieb:
> psycopg2.OperationalError: FEHLER: konnte auf den Status von Transaktion 3279045664 nicht zugreifen
> DETAIL: Konnte Datei »pg_clog/0C37« nicht öffnen: Datei oder Verzeichnis nicht gefunden.
[...]
> Was sind das für Dateien ig pg_clog und warum können die verschwinden?

Da steht drinnen, welche Transaktion mit COMMIT und welche mit ROLLBACK
abgeschlossen wurden ("Commit LOG").

Der Fehler muß nicht notwendigerweise heißen, daß die CLOG-Datei Verschwunden ist.
Oft bedeutet es, daß ein Block in der Tabelle kaputt ist. Dann verweist die Tabellenzeile
zum Beispiel auf Transaktion 3279045664, obwohl es die gar nie gegeben hat.
Dann gibt es natürlich auch keine CLOG-Datei für diese Transaktion.

Wenn solche Fehler reproduzierbar sind, ist die Datenbank korrupt; ich würde, wenn
möglich, auf ein Backup zurückgreifen.

Liebe Grüße,
Laurenz Albe

Am 14.02.2012 10:53, schrieb Andreas Tille:
> Was sind das für Dateien ig pg_clog und warum können die verschwinden?
> Viele Grüße Andreas.

Hallo Andreas,

pg_clog ist in der Regel leer. Da werden nur dann Commit-Logs
ausgelagert, wenn der RAM nicht reicht.

Die Dateien, die er nicht findet - haben dort vermutlich nie gelegen,
sondern immer nur in Deinem RAM.

Hast Du versucht eine Replikation aufzusetzen?
Hast Du pg_upgrade benutzt?
Hast Du ein Hot-Backup gemacht?
Versuchst Du von 32- auf 64 Bit zu wechseln?

Du möchtest wissen, wie Du es reparieren kannst.

Da gibt es eigentlich nur eine Möglichkeit:
Backup einspielen und Point in Time Recovery.

Ein schönes Wochenende,

Susanne

--
Dipl. Inf. Susanne Ebrecht - 2ndQuadrant
PostgreSQL Development, 24x7 Support, Training and Services
www.2ndQuadrant.com

Hallo Susanne,

On Sat, Feb 18, 2012 at 10:42:55PM +0100, Susanne Ebrecht wrote:
> ...
> Da gibt es eigentlich nur eine Möglichkeit:
> Backup einspielen und Point in Time Recovery.

Danke für die Antwort. Ja ich habe ein Backup eingespielt, was im Fall
der Debian Ultimate Database sehr einfach ist, denn ich betreibe nur
einen Clone und habe einfach nur das Original noch mal eingespielt.
Seitdem gab es keine Probleme mehr und ich hoffe, daß das so bleibt.

Viele Grüße

Andreas.

--
http://fam-tille.de

Susanne Ebrecht schrieb:
> Am 14.02.2012 10:53, schrieb Andreas Tille:
>> Was sind das für Dateien ig pg_clog und warum können die verschwinden?
>> Viele Grüße Andreas.
>
> pg_clog ist in der Regel leer. Da werden nur dann Commit-Logs
> ausgelagert, wenn der RAM nicht reicht.

Wenn das war wäre, und es gäbe einen Crash, wie würde das System
dann den Commit-Status von Transaktionen herausfinden, die vor dem
letzten Checkpoint passiert sind?

Liebe Grüße,
Laurenz Albe

Hi,

dafür müsste glaub ich pg_xlog da sein

Gruss
Thomas

Am 20.02.2012 10:46, schrieb Albe Laurenz:
> Susanne Ebrecht schrieb:
>> Am 14.02.2012 10:53, schrieb Andreas Tille:
>>> Was sind das für Dateien ig pg_clog und warum können die verschwinden?
>>> Viele Grüße Andreas.
>> pg_clog ist in der Regel leer. Da werden nur dann Commit-Logs
>> ausgelagert, wenn der RAM nicht reicht.
> Wenn das war wäre, und es gäbe einen Crash, wie würde das System
> dann den Commit-Status von Transaktionen herausfinden, die vor dem
> letzten Checkpoint passiert sind?
>
> Liebe Grüße,
> Laurenz Albe
>

Am 20.02.2012 10:46, schrieb Albe Laurenz:
> Susanne Ebrecht schrieb:
>> Am 14.02.2012 10:53, schrieb Andreas Tille:
>>> Was sind das für Dateien ig pg_clog und warum können die verschwinden?
>>> Viele Grüße Andreas.
>> pg_clog ist in der Regel leer. Da werden nur dann Commit-Logs
>> ausgelagert, wenn der RAM nicht reicht.
> Wenn das war wäre, und es gäbe einen Crash, wie würde das System
> dann den Commit-Status von Transaktionen herausfinden, die vor dem
> letzten Checkpoint passiert sind?

Lass es mich mal von vorne erkläre:

Von prepared Transactions abgesehen ist, arbeitet SQL nach dem
Ein-Phasen-Commit-Prinzip. Heisst Du schickt "Commit" und bekommst "ACK"
zurück,
wenn es geklappt hat.

Du startest eine Transaktion -
Zwischenschritte und so weiter werden im RAM festgehalten und wenn RAM
nicht reicht,
in pg_clog bzw. pg_subtrans ausgelagert. Subtransaktionen werden - je
nach Art der Subtransaktion
entweder in pg_clog oder in pg_subtrans ausgelagert. Das kommt auf die
Subtransaktion an.

Wenn Du das Commit abfeuerst - dann wird alles permanent in pg_xlog
gespeichert.
Erst wenn alles permanent (auf der Festplatte) in pg_xlog abgelegt
wurde, bekommst Du
das "ACK" zurück. Im psql z.B. bekommst Du dann den Prompt wieder.
Erst dann gilt es als committed.

Vorausgesetzt natürlich, dass Du synchronous_commit nicht abgeschaltet hast.

Wenn Dir der Server abraucht, bevor oder während des Commits - dann ist
die Transaktion
verloren. Dann hast Du aber auch keine Bestätigung bekommen, dass die
Transaktion abgeschlossen
wurde.

Susanne

--
Dipl. Inf. Susanne Ebrecht - 2ndQuadrant
PostgreSQL Development, 24x7 Support, Training and Services
www.2ndQuadrant.com

Am 20. Februar 2012 11:59 schrieb Susanne Ebrecht <susanne(at)2ndquadrant(dot)com>:

> Am 20.02.2012 10:46, schrieb Albe Laurenz:
>>
>> Susanne Ebrecht schrieb:
>>
>>> pg_clog ist in der Regel leer. Da werden nur dann Commit-Logs
>>> ausgelagert, wenn der RAM nicht reicht.
>>
>> Wenn das war wäre, und es gäbe einen Crash, wie würde das System
>> dann den Commit-Status von Transaktionen herausfinden, die vor dem
>> letzten Checkpoint passiert sind?

[..]

> Wenn Du das Commit abfeuerst - dann wird alles permanent in pg_xlog
> gespeichert.

Bis die WAL-Segmente recycled werden. Von dem Moment an, braucht man
die entsprechende CLOG-Stücken auf der Platte zu haben und
beizubehalten bis alle Tabellen keine zu alten unfrozen Zeilen mehr
haben (sonst kann man gerollbackte Zeilen nicht als solche erkennen).
Ich weiß nicht genau wann CLOG in den OS-Cache geschrieben wird,
spätestens aber wird es also beim Checkpointing geschrieben + fsynced.

Nicolas

--
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?

Susanne Ebrecht schrieb:
>> Susanne Ebrecht schrieb:
>>> Am 14.02.2012 10:53, schrieb Andreas Tille:
>>>> Was sind das für Dateien ig pg_clog und warum können die verschwinden?
>>>> Viele Grüße Andreas.

>>> pg_clog ist in der Regel leer. Da werden nur dann Commit-Logs
>>> ausgelagert, wenn der RAM nicht reicht.

>> Wenn das war wäre, und es gäbe einen Crash, wie würde das System
>> dann den Commit-Status von Transaktionen herausfinden, die vor dem
>> letzten Checkpoint passiert sind?

> Lass es mich mal von vorne erkläre:
>
> Von prepared Transactions abgesehen ist, arbeitet SQL nach dem
> Ein-Phasen-Commit-Prinzip. Heisst Du schickt "Commit" und bekommst "ACK"
> zurück,
> wenn es geklappt hat.
>
> Du startest eine Transaktion -
> Zwischenschritte und so weiter werden im RAM festgehalten und wenn RAM
> nicht reicht,
> in pg_clog bzw. pg_subtrans ausgelagert. Subtransaktionen werden - je
> nach Art der Subtransaktion
> entweder in pg_clog oder in pg_subtrans ausgelagert. Das kommt auf die
> Subtransaktion an.
>
> Wenn Du das Commit abfeuerst - dann wird alles permanent in pg_xlog
> gespeichert.
[...]

Lies Die Antwort von Nicolas Barbier.
Lies auch http://wiki.postgresql.org/wiki/Hint_Bits
Und src/backend/access/transam/xlog.c und src/backend/access/transam/clog.c

Wenn eine Transaktion abgeschlossen wird, wird WAL in pg_xlog geschrieben,
das beschreibt, wie die Änderungen der Transaktion nachgespielt
werden können.

Die Datenblöcke (buffer) selber werden dabei nicht berührt, stattdessen wird
das CLOG für die Transaktion aktualisiert (das daweil noch in RAM ist).
Darin sieht man, in welchem Zustand die Transaktion ist.

Spätestens bei einem Checkpoint (siehe CheckPointGuts() und
CheckPointCLOG() im Code) werden CLOG-Einträge auf Platte geschrieben.

Erst wenn alle Transaktionen in einer CLOG-Page "frozen" sind,
kann die CLOG-Page entfernt werden (siehe TruncateCLOG()).

Wer als erstes nach Transaktionsende die neue Tabellenzeile lesen
kommt, stellt fest, daß die Hint Bits nicht gesetzt sind und geht
im CLOG nachschauen, wie die Transaktion, die die Zeile geschrieben
hat, abgeschlossen wurde. Dann werden die Hint Bits für zukünftige Leser
als Abkürzung gesetzt.

Darauf zielte meine Frage, die Du wahrscheinlich mißverstanden hast, ab:
Wenn es einen Crash gibt, wird ab dem letzten Checkpoint das WAL
nachgespielt. Was vor dem letzten Checkpoint war, muß auf Platte sein,
also auch CLOG, denn sonst könne man von so einer Transaktion nicht
mehr sagen, wie sie abgeschlossen wurde. Das WAL zu durchstöbern,
wäre nicht nur entsetzlich langwierig, sondern es ist auch gar nicht
garantiert, daß es das entsprechende WAL-Segment überhaupt noch gibt.

Liebe Grüße,
Laurenz

Am 20.02.2012 15:26, schrieb Albe Laurenz:
> Darauf zielte meine Frage, die Du wahrscheinlich mißverstanden hast,
> ab: Wenn es einen Crash gibt, wird ab dem letzten Checkpoint das WAL
> nachgespielt. Was vor dem letzten Checkpoint war, muß auf Platte sein,
> also auch CLOG, denn sonst könne man von so einer Transaktion nicht
> mehr sagen, wie sie abgeschlossen wurde. Das WAL zu durchstöbern, wäre
> nicht nur entsetzlich langwierig, sondern es ist auch gar nicht
> garantiert, daß es das entsprechende WAL-Segment überhaupt noch gibt.
> Liebe Grüße, Laurenz

Das stimmt so nicht. Wenn ein Crash passiert ist - wird beim Restart
geprüft, wann der letzte Checkpoint war, alles was danach war wird aus
den WAL bzw. Redo nachgezogen.
WAL Dateien werden erst überschrieben, nachdem zwei Checkpoints passiert
sind.
Ja ich weiss, in der Doku steht, sie werden schon nach dem ersten
überschrieben, aber tatsächlich
werden sie erst nach dem zweiten Durchlauf überschrieben.

Was vor dem letzten Checkpoint war - ist schon im Base angekommen. Das
liegt schon fest auf der Platte. Das ist schon im Datenverzeichnis
angekommen.

PostgreSQL speichert erstmal alles permanent im WAL - wenn ein
Checkpoint passiert wird dann alles auf die Platte i.d.r. ins base
geschrieben.

Die genaue Beschreibung, was pg_clog macht, findest Du hier:

http://wiki.postgresql.org/wiki/Hint_Bits

Susanne

--
Dipl. Inf. Susanne Ebrecht - 2ndQuadrant
PostgreSQL Development, 24x7 Support, Training and Services
www.2ndQuadrant.com

Susanne Ebrecht wrote:
> > Darauf zielte meine Frage, die Du wahrscheinlich mißverstanden hast,
> > ab: Wenn es einen Crash gibt, wird ab dem letzten Checkpoint das WAL
> > nachgespielt. Was vor dem letzten Checkpoint war, muß auf Platte sein,
> > also auch CLOG, denn sonst könne man von so einer Transaktion nicht
> > mehr sagen, wie sie abgeschlossen wurde. Das WAL zu durchstöbern, wäre
> > nicht nur entsetzlich langwierig, sondern es ist auch gar nicht
> > garantiert, daß es das entsprechende WAL-Segment überhaupt noch gibt.
>
> Das stimmt so nicht. Wenn ein Crash passiert ist - wird beim Restart
> geprüft, wann der letzte Checkpoint war, alles was danach war wird aus
> den WAL bzw. Redo nachgezogen.
> WAL Dateien werden erst überschrieben, nachdem zwei Checkpoints passiert
> sind.
> Ja ich weiss, in der Doku steht, sie werden schon nach dem ersten
> überschrieben, aber tatsächlich
> werden sie erst nach dem zweiten Durchlauf überschrieben.
>
> Was vor dem letzten Checkpoint war - ist schon im Base angekommen. Das
> liegt schon fest auf der Platte. Das ist schon im Datenverzeichnis
> angekommen.
>
> PostgreSQL speichert erstmal alles permanent im WAL - wenn ein
> Checkpoint passiert wird dann alles auf die Platte i.d.r. ins base
> geschrieben.
>
> Die genaue Beschreibung, was pg_clog macht, findest Du hier:
>
> http://wiki.postgresql.org/wiki/Hint_Bits

Du weichst aus :^)

Mein Argument hängt gar nicht davon ab, ob WAL erst nach einem oder
erst nach 2 Checkpoints überschrieben wird.

Was vor dem letzten Checkpoint war, ist tatsächlich schon auf Platte -
aber eben genau deshalb, weil auch das CLOG dann auf Platte geschrieben
wird und nicht, wie Du ursprünglich behauptet hast, nur dann, wenn
es nicht mehr ins Memory paßt.

Und eigentlich ist es nicht notwendig, darüber zu streiten, weil ein
Blick in den Code das überflüssig macht.

Es geht mir nicht darum, Deinen Irrtum anzuprangern, aber die
ursprüngliche Frage, was in pg_clog eigentlich drinnensteht, sollte
meiner Meinung nach korrekt beantwortet werden.

Liebe Grüße,
Laurenz Albe

Am 21.02.2012 10:04, schrieb Albe Laurenz:
> Es geht mir nicht darum, Deinen Irrtum anzuprangern, aber die
> ursprüngliche Frage, was in pg_clog eigentlich drinnensteht, sollte
> meiner Meinung nach korrekt beantwortet werden. Liebe Grüße, Laurenz Albe

Ich denke, wir meinen eh das gleiche und reden nur nett aneinander vorbei.

Und dem User hilft es gar nichts - weil bei einem solchen Crash ist das
einfachste
das Backup einzuspielen.

Susanne

--
Dipl. Inf. Susanne Ebrecht - 2ndQuadrant
PostgreSQL Development, 24x7 Support, Training and Services
www.2ndQuadrant.com

On Jan 31, 2012, at 4:20 PM, Bernd Helmle wrote:

>
>
> --On 27. Januar 2012 18:00:33 +0100 Andreas Kretschmer <akretschmer(at)spamfence(dot)net> wrote:
>
>>> Traceback (most recent call last):
>>> File "./bug_close_history.py", line 101, in <module>
>>> curs.execute(query)
>>> psycopg2.OperationalError: FEHLER: konnte auf den Status von Transaktion
>>> 3301449728 nicht zugreifen DETAIL: Konnte Datei »pg_clog/0C4C« nicht
>>> öffnen: Datei oder Verzeichnis nicht gefunden.
>>
>> Das ist das Problem.
>>
>> Woran das liegt kann ich Dir nicht sagen, defekte Platte wäre eine
>> Option.
>
> Das kann vielfältige Ursachen haben, von Problemen mit Filesystem bis hin
> zu defekten Tupelheadern, verursacht bspw. durch defektes RAM. Alternativ kämen noch Probleme mit pg_upgrade hinzu.
>
> Eine Chance, dass diese Instanz in der Vergangenheit mit pg_upgrade "behandelt" wurde?
>
> --
> Thanks
>
> Bernd

das stimmt, das kann alles sein …
ich persönlich bin aber noch nicht ganz davon überzeugt, dass wirklich alles bugs aus der clog implementierung raus sind …
wir haben auch schon fehler gesehen, die weder ram noch filesystem waren.
das coole daran ist, dass man das de facto nicht "provozieren" kann …
in den letzten jahren hat es den ein oder anderen clog fix gegeben - das hats verbessert.
aber, so 100% sicher, dass alle bugs raus sind, bin ich mir nicht … ich habe selber schon viel im code gegraben aber irgendwie noch keinen anhaltspunkt gefunden,.

liebe grüße,

hans

--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de