Re: Summary and Plan for Hot Standby

On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote:

> - The assumption that b-tree vacuum records don't need conflict
> resolution because we did that with the additional cleanup-info record
> works ATM, but it hinges on the fact that we don't delete any tuples
> marked as killed while we do the vacuum. That seems like a low-hanging
> fruit that I'd actually like to do now that I spotted it, but will then
> need to fix b-tree vacuum records accordingly. 

You didn't make a change, so I wonder whether you realised no change was
required or that you still think change is necessary, but have left it
to me? Not sure.

I've investigated this but can't see any problem or need for change.

btvacuumpage() is very specific about deleting *only* index tuples that
have been collected during the VACUUM's heap scan, as identified by the
heap callback function, lazy_tid_reaped().

There is no reliance at all on the state of the index tuple. If you
ain't on the list, you ain't cleaned. I accept your observation that
some additional index tuples may be marked as killed by backends
accessing the table that is being vacuumed, since those backends could
have a RecentGlobalXmin later than the OldestXmin used by the VACUUM as
a result of the change that means GetSnapshotData() ignores lazy
vacuums. But those tuples will not be identified by the callback
function and so the "additionally killed" index tuples will not be
removed.

It is a possible future optimisation of b-tree vacuum that it cleans
these additional killed tuples while it executes, but it doesn't do it
now and so we need not worry about that for HS.

I think its important that we note this assumption though.

Comment?

-- Simon Riggs           www.2ndQuadrant.com