Re: heap vacuum & cleanup locks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: heap vacuum & cleanup locks
Date: 2011-11-08 15:54:44
Message-ID: 21734.1320767684@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Albe Laurenz 2011-11-08 15:59:02 Re: Disable OpenSSL compression
Previous Message Robert Haas 2011-11-08 15:50:04 Re: heap vacuum & cleanup locks