Re: FSM rewrite committed, loose ends
От | Zdenek Kotala |
---|---|
Тема | Re: FSM rewrite committed, loose ends |
Дата | |
Msg-id | 48E4872A.1010001@sun.com обсуждение исходный текст |
Ответ на | Re: FSM rewrite committed, loose ends (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | 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 по дате отправления: