On Tue, Nov 8, 2011 at 10:26 AM, Tom Lane <t...@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);
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
