To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>, pgsql-hackers@postgresql.org
Subject: Re: SSI atomic commit 
In-reply-to: <4E161881.6090800@enterprisedb.com> 
References: <4E12FDA8020000250003EFC1@gw.wicourts.gov>
	<4E15D48A.7080203@enterprisedb.com>
	<4E159B5C020000250003F063@gw.wicourts.gov>
	<4E160005.1020300@enterprisedb.com>
	<4E161881.6090800@enterprisedb.com>
Comments: In-reply-to Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
	message dated "Thu, 07 Jul 2011 23:35:13 +0300"
Date: Thu, 07 Jul 2011 16:48:55 -0400
Message-ID: <2648.1310071735@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Kevin and Dan also pointed out that a 2PC transaction can stay in 
> prepared state for a long time, and we could optimize that by setting 
> prepareSeqNo only at the final COMMIT PREPARED. I objected to that, for 
> the reason that it's currently very convenient for testing purposes that 
> a transaction prepared with PREPARE TRANSACTION is in the exact same 
> state as regular transaction that's going through regular commit processing.

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?

			regards, tom lane