Skip site navigation (1) Skip section navigation (2)

Re: pika buildfarm member failure on isolationCheck tests

From: Dan Ports <drkp(at)csail(dot)mit(dot)edu>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: R?mi Zara <remi_zara(at)mac(dot)com>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>,Andrew Dunstan <andrew(at)dunslane(dot)net>,Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>,Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Subject: Re: pika buildfarm member failure on isolationCheck tests
Date: 2011-06-20 09:15:29
Message-ID: 20110620091529.GG83336@csail.mit.edu (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sun, Jun 19, 2011 at 09:10:02PM -0400, Robert Haas wrote:
> Is this an open item for 9.1beta3?

Yes. I've put it on the list.

The SxactGlobalXmin and its refcount were getting out of sync with the
actual transaction state. This is timing-dependent but I can reproduce it
fairly reliably under concurrent workloads.

It looks the problem comes from the change a couple days ago that
removed the SXACT_FLAG_ROLLED_BACK flag and changed the
SxactIsRolledBack checks to SxactIsDoomed. That's the correct thing to
do everywhere else, but gets us in trouble here. We shouldn't be
ignoring doomed transactions in SetNewSxactGlobalXmin, because they're
not eligible for cleanup until the associated backend aborts the
transaction and calls ReleasePredicateLocks.

However, it isn't as simple as just removing the SxactIsDoomed check
from SetNewSxactGlobalXmin. ReleasePredicateLocks calls
SetNewSxactGlobalXmin *before* it releases the aborted transaction's
SerializableXact (it pretty much has to, because we must drop and
reacquire SerializableXactHashLock in between). But we don't want the
aborted transaction included in the SxactGlobalXmin computation.

It seems like we do need that SXACT_FLAG_ROLLED_BACK after all, even
though it's only set for this brief interval. We need to be able to
distinguish a transaction that's just been marked for death (doomed)
from one that's already called ReleasePredicateLocks.

Dan

-- 
Dan R. K. Ports              MIT CSAIL                http://drkp.net/

In response to

Responses

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2011-06-20 09:49:05
Subject: patch: plpgsql - remove unnecessary ccache search when a array variable is updated
Previous:From: Simon RiggsDate: 2011-06-20 08:48:49
Subject: Re: ALTER TABLE lock strength reduction patch is unsafe

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group