Horton

Re: heap vacuum & cleanup locks

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-11-08T15:54:44Z
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.

Robert Haas <robertmhaas@gmail.com> writes:
> 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

Hmm ... I think that code is OK but the comment needs work.  Here we are
necessarily looking for a pretty recent value of xmin (it has to be
later than GlobalXmin), so there's no need to worry that it might get
changed to FrozenXID.

			regards, tom lane