Re: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle

From: Florian Pflug <fgp(at)phlo(dot)org>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle
Date: 2010-05-13 23:02:48
Message-ID: 678A05F6-9158-40A2-9D7F-B0BC72016358@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On May 13, 2010, at 23:51 , Kevin Grittner wrote:

> Florian Pflug <fgp(at)phlo(dot)org> wrote:
>
>> All in all, I believe that SHARE and UPDATE row-level locks should
>> be changed to cause concurrent UPDATEs to fail with a
>> serialization error. I can come up with a patch that does that,
>> but I wanted to get some feedback on the idea before I put the
>> work in.
>
> Before you work on that, you might want to wait until you can review
> the work that I and Dan Ports (a Ph.D. candidate from MIT) have been
> doing on support for true serializable transactions. You don't need
> to use FOR SHARE or FOR UPDATE or any explicit locks as long as the
> concurrent transactions are SERIALIZABLE. We have it working, but
> have been holding off on discussion or patch submission at Tom's
> request -- he felt it would distract from the process of getting the
> release out.

I'm very exited about the work you're doing there, and believe it'd be a great feature to have.

However, I view my proposal as pretty orthogonal to that work. True serializable transaction are much more powerful than what I proposed, but at a much higher price too, due to the necessity of SIREAD locks. My proposal allows for simple FK-like constraints to be implemented at user-level that are correct for all isolation levels.

best regards,
Florian Pflug

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2010-05-14 00:13:51 Re: pg_upgrade code questions
Previous Message Florian Pflug 2010-05-13 22:52:46 Re: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle