Re: FSM rewrite committed, loose ends - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: FSM rewrite committed, loose ends
Date
Msg-id 48E4872A.1010001@sun.com
Whole thread Raw
In response to Re: FSM rewrite committed, loose ends  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List 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




pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: [SPAM?]: Re: Block-level CRC checks
Next
From: Greg Stark
Date:
Subject: Re: Common Table Expressions (WITH RECURSIVE) patch