To: Robert Haas <robertmhaas@gmail.com>
cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>,
	pgsql-hackers@postgresql.org
Subject: Re: SSI atomic commit 
In-reply-to: 
 <CA+Tgmoba7_6Hq4q0+uDQ=TBteic6s44aTfMpcEndzQhqSjQYuQ@mail.gmail.com>
References: <4E12FDA8020000250003EFC1@gw.wicourts.gov>
	<4E13516F.50301@enterprisedb.com> <21785.1309889780@sss.pgh.pa.us>
	<4E131329020000250003EFE3@gw.wicourts.gov>
	<CA+Tgmoba7_6Hq4q0+uDQ=TBteic6s44aTfMpcEndzQhqSjQYuQ@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Tue, 05 Jul 2011 15:17:48 -0400"
Date: Tue, 05 Jul 2011 15:30:43 -0400
Message-ID: <23263.1309894243@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jul 5, 2011 at 2:35 PM, Kevin Grittner
> <Kevin.Grittner@wicourts.gov> wrote:
>> That's easily done if we don't mind taking out a ProcArrayLock
>> during completion of a transaction which has no XID, if only long
>> enough to increment a uint64 in shared memory, and then stash the
>> value -- somewhere -- so that SSI code can find and use it.

> That sure sounds scary from a scalability perspective.  If we can
> piggyback on an existing ProcArrayLock acquisition, fine, but
> additional ProcArrayLock acquisitions when SSI isn't even being used
> sound like a real bad idea to me.

Isn't SSI *already* forcing a new acquisition of an LWLock during
commits of read-only transactions that aren't using SSI?  Perhaps
there's a bit less contention on SerializableXactHashLock than on
ProcArrayLock, but it's not obvious that the current situation is
a lot better than this would be.

			regards, tom lane