On Tue, 2007-02-27 at 00:55 -0500, Tom Lane wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> 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
