Re: SSI atomic commit

Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Jul 5, 2011 at 2:35 PM, Kevin Grittner
> <Kevin.Grittner@wicourts.gov> wrote:
>>> It'd be better to push some functionality into the procarray
>>> code.
>>
>> 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.  I doubt you'll notice much
> of a performance regression in the current code, but if/when we
> fix the lock manager bottlenecks that my fastlock and lazy vxid
> lock patches are intended to correct, then I suspect it's going to
> matter quite a bit.
Just to be clear, the patch as submitted does *not* acquire a
ProcArrayLock lock for completion of a transaction which has no XID.
What you quoted from me was explaining what would seem to be
required (unless Dan and I missed something) to simplify the patch
as Tom and Heikki proposed.  We saw that approach and its
simplicity, but shied away from it because of the locking issue and
its potential performance impact.
We took the route we did in this fix patch to avoid such issues. 
I'm not so sure that the impact on a load of many short read-only
transactions would be so benign as things stand.  It seemed to me
that one of the reasons to avoid *getting* an XID was to avoid
acquiring ProcArrayLock on transaction completion.  The way we did
this patch may indeed slow serializable transactions more than the
alternative; but from the beginning I thought the ground rules were
that SSI had to have no significant impact on those who didn't
choose to use it.
I suspect that most of the 9.2 work on SSI will be for improved
performance (including in that, as I do, a reduction in the
percentage of false positive serialization failures).  Tuning this
should go on that list.  It may well benefit from using some of the
techniques you've been working on.
-Kevin