Robert Haas <robertmh...@gmail.com> writes:
> On Tue, Jul 5, 2011 at 2:35 PM, Kevin Grittner
> <kevin.gritt...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
