| From: | Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com> |
|---|---|
| To: | Susanne Ebrecht <susanne(at)2ndquadrant(dot)com> |
| Cc: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, pgsql-de-allgemein(at)postgresql(dot)org |
| Subject: | Re: Re: FEHLER: konnte auf den Status von Transaktion XY nicht zugreifen |
| Date: | 2012-02-20 12:24:30 |
| Message-ID: | CAP-rdTaK6p9cfnoK2ACbEjUSU7oz+=j8jzERa7fisouE7oaAyQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-de-allgemein |
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?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Albe Laurenz | 2012-02-20 14:26:11 | Re: Re: FEHLER: konnte auf den Status von Transaktion XY nicht zugreifen |
| Previous Message | Susanne Ebrecht | 2012-02-20 10:59:42 | Re: Re: FEHLER: konnte auf den Status von Transaktion XY nicht zugreifen |