On Tue, Nov 8, 2011 at 10:26 AM, Tom Lane <tgl@sss.pgh.pa.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);
returnNULL; }
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
