Horton

Re: heap vacuum & cleanup locks

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Simon Riggs <simon@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-11-08T15:50:04Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Make VACUUM avoid waiting for a cleanup lock, where possible.

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);
                                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