From: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: FSM rewrite committed, loose ends |
Date: | 2008-10-02 08:32:42 |
Message-ID: | 48E4872A.1010001@sun.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas napsal(a):
> Zdenek Kotala wrote:
>> Heikki Linnakangas napsal(a):
>>> The FSM is not updated during WAL replay. That means that after crash
>>> recovery, the FSM won't be completely up-to-date, but at roughly the
>>> state it was at last checkpoint. In a warm stand-by, the FSM will
>>> reflect the situation at last full backup. We need to think when the
>>> FSM should be updated during WAL replay. Probably not after every
>>> record, because of the overhead, but certainly more often than never.
>>
>> What's about after a page write during a WAL replay?
>
> You mean when a page is evicted from the buffer cache?
Yes
> That might be
> pretty good from performance point of view, but from a modularity point
> of view, the buffer manager should have no business modifying the FSM.
Yeah, it is true. I suggest to try modify FMS info on each manipulation
in WAL replay and if it will have performance issue we can start think
about improvements.
Zdenek
From | Date | Subject | |
---|---|---|---|
Next Message | Albe Laurenz | 2008-10-02 09:01:37 | Re: Transactions within a function body |
Previous Message | Hannu Krosing | 2008-10-02 08:28:57 | Re: [SPAM?]: Re: Block-level CRC checks |