Re: heap vacuum & cleanup locks

On Tue, Nov 8, 2011 at 10:26 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> It strikes me that the only case where vacuum now has to wait is where
> it needs to freeze an old XID.  Couldn't it do that without insisting on
> exclusive access?  We only need exclusive access if we're going to move
> data around, but we could have a code path in vacuum that just replaces
> old XIDs with FrozenXID without moving/deleting anything.

Interesting idea. I think in general we insist that you must have a
buffer content lock to inspect the tuple visibility info, in which
case that would be safe. But I'm not sure we do that absolutely
everywhere. For instance, just last night I noticed this:

/*
* If xmin isn't what we're expecting, the
slot must have been
* recycled and reused for an unrelated tuple.
This implies that
* the latest version of the row was deleted,
so we need do
* nothing. (Should be safe to examine xmin
without getting
* buffer's content lock, since xmin never
changes in an existing
* tuple.)
*/
if
(!TransactionIdEquals(HeapTupleHeaderGetXmin(tuple.t_data),

priorXmax))
{
ReleaseBuffer(buffer);
return NULL;
}

Maybe we can convince ourselves that that case is OK, or fixable; I'm
not sure whether there are any others.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company