Date: Thu, 7 Jul 2011 17:08:07 -0400
From: Dan Ports <drkp@csail.mit.edu>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>,
	Kevin Grittner <Kevin.Grittner@wicourts.gov>, pgsql-hackers@postgresql.org
Subject: Re: SSI atomic commit
Message-ID: <20110707210807.GE76634@csail.mit.edu>
References: <4E12FDA8020000250003EFC1@gw.wicourts.gov>
	<4E15D48A.7080203@enterprisedb.com>
	<4E159B5C020000250003F063@gw.wicourts.gov>
	<4E160005.1020300@enterprisedb.com>
	<4E161881.6090800@enterprisedb.com> <2648.1310071735@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2648.1310071735@sss.pgh.pa.us>
User-Agent: Mutt/1.5.21 (2010-09-15)

On Thu, Jul 07, 2011 at 04:48:55PM -0400, Tom Lane wrote:
> Seems to me there's a more fundamental reason not to do that, which is
> that once you've done PREPARE it is no longer legitimate to decide to
> roll back the transaction to get out of a "dangerous" structure --- ie,
> you have to target one of the other xacts involved instead.  Shouldn't
> the assignment of a prepareSeqNo correspond to the point where the xact
> is no longer a target for SSI rollback?

That part is already accomplished by setting SXACT_FLAG_PREPARED (and
choosing a new victim if we think we want to abort a transaction with
that flag set).

prepareSeqNo is being used as a lower bound on the transaction's commit
sequence number. It's currently set at the same time as the PREPARED
flag, but it doesn't have to be.

Dan

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