Skip site navigation (1) Skip section navigation (2)

Re: A third lock method

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: A third lock method
Date: 2009-12-30 23:25:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Kevin Grittner wrote:
> I've been reviewing code to get a better handle on the scope of
> changes to support serializable transactions, in preparation for
> next month's meetings with our CIO.  My posts should start getting
> progressively less hand-wavy.  :-)
> I've come to a few conclusions:
> (1)  The notions of having multiple serializable implementations
> (SSI, S2PL, OCC) which can be mapped as a configuration option is
> really not worth it.  The cases where S2PL or OCC beat SSI are too
> narrow to be worth the effort, and the pluggable approach seems like
> it would be much more invasive and destabilizing than just picking
> one and doing it more directly.


> (2)  If we're going with SSI, it appears that it would be a very
> good idea to define a third lock method (SIREAD_LOCKMETHOD perhaps)
> for the SIREAD locks.  For one thing, that could keep them out of
> the way of normal conflict detection (they don't conflict with
> anything, per se) and out of the way of deadlock detection,
> including rearrangement of waiting transactions.  For another, they
> have a different life-cycle -- they must stick around (along with
> some minimal transaction information) until all transactions with a
> snapshot prior to their commit have completed.  That seems cleaner
> and easier with a separate lock method.

I must be missing something but I thought the only problem with our
existing snapshot system was that you could see a row updated after your
snapshot was created, and that the solution to that was to abort the
transaction that would see the new row.  Can you tell me what I am

  Bruce Momjian  <bruce(at)momjian(dot)us>

  + If your life is a hard drive, Christ can be your backup. +

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2009-12-30 23:26:10
Subject: Re: Allowing x IS NOT NULL as a btree search condition
Previous:From: Tom LaneDate: 2009-12-30 23:23:41
Subject: Allowing x IS NOT NULL as a btree search condition

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group