Re: Updating FSM on recovery - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Updating FSM on recovery
Date
Msg-id 24334.1225205478@sss.pgh.pa.us
Whole thread Raw
In response to Updating FSM on recovery  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Updating FSM on recovery
List pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> So we should try to update the FSM during recovery as well. It doesn't 
> need to be very accurate, as the FSM information isn't accurate anyway, 
> but we should try to avoid the worst case scenarios.

Agreed.

> One issue with this patch is that it doesn't update the FSM at all when 
> pages are restored from full page images. It would require fetching the 
> page and checking the free space on it, or peeking into the size of the 
> backup block data, and I'm not sure if it's worth the extra code to do that.

I'd vote not to bother, at least not in the first cut.  As you say, 100%
accuracy isn't required, and I think that in typical scenarios an
insert/update that causes a page to become full would be relatively less
likely to have a full-page image.

As far as the ugliness in XLogRecordPageWithFreeSpace goes: couldn't you
just call XLogReadBufferWithFork with init = true, and then initialize
the page if PageIsNew?
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Proposal of PITR performance improvement for 8.4.
Next
From: Dimitri Fontaine
Date:
Subject: Re: WIP patch: convert SQL-language functions to return tuplestores