Re: FSM rewrite committed, loose ends

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

In response to

Browse pgsql-hackers by date

  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