On Tue, 2007-02-27 at 00:55 -0500, Tom Lane wrote:
> "Jim C. Nasby" <jim@nasby.net> writes:
> > Yes, DSM would make FSM recovery more important, but I thought it was
> > recoverable now? Or is that only on a clean shutdown?
>
> Currently we throw away FSM during any non-clean restart. This is
> probably overkill but I'm quite unclear what would be a safe
> alternative.
>
> > I suspect we don't need perfect recoverability...
>
> The main problem with the levels proposed by Takahiro-san is that any
> transition from FROZEN to not-FROZEN *must* be exactly recovered,
> because vacuum will never visit an allegedly frozen page at all. This
> appears to require WAL-logging DSM state changes, which is a pretty
> serious performance hit. I'd be happier if the DSM content could be
> treated as just a hint. I think that means not trusting it for whether
> a page is frozen to the extent of not needing vacuum even for
> wraparound.

Agreed.

> So I'm inclined to propose that there be only two states
> (hence only one DSM bit per page): page needs vacuum for space recovery,
> or not. Vacuum for XID wraparound would have to hit every page
> regardless.

I'm inclined to think: this close to deadline it would be more robust to
go with the simpler option. So, agreed to the one bit per page.

We can revisit the 2 bits/page idea easily for later releases. If the
DSM is non-transactional, upgrading to a new format in the future should
be very easy.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org