Re: A design for amcheck heapam verification

On Mon, May 1, 2017 at 9:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> ISTM if you want to do that you have an inherent race condition.
> That is, no matter what you do, the moment after you look the currently
> oldest open transaction could commit, allowing some other session's
> view of RecentGlobalXmin to move past what you think it is, so that
> that session could start pruning stuff.

It can't prune the stuff we care about if we've got a shared content
lock on the target buffer.  That's the trick pg_visibility uses:

                               /*
                                 * Time has passed since we computed
OldestXmin, so it's
                                 * possible that this tuple is
all-visible in reality even
                                 * though it doesn't appear so based on our
                                 * previously-computed value.  Let's
compute a new value so we
                                 * can be certain whether there is a problem.
                                 *
                                 * From a concurrency point of view,
it sort of sucks to
                                 * retake ProcArrayLock here while
we're holding the buffer
                                 * exclusively locked, but it should
be safe against
                                 * deadlocks, because surely
GetOldestXmin() should never take
                                 * a buffer lock. And this shouldn't
happen often, so it's
                                 * worth being careful so as to avoid
false positives.
                                 */

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company