From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: SSI atomic commit
Date: Tue, 05 Jul 2011 15:30:43 -0400
Message-ID: <23263.1309894243@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, Kevin.Grittner@wicourts.gov, heikki.linnakangas@enterprisedb.com
Subject: Re: SSI atomic commit
In-Reply-To: <23263.1309894243@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox