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

Re: Serializable Isolation without blocking

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <gsstark(at)mit(dot)edu>
Cc: <nicolas(dot)barbier(at)gmail(dot)com>,<pgsql-hackers(at)postgresql(dot)org>, <laurenz(dot)albe(at)wien(dot)gv(dot)at>
Subject: Re: Serializable Isolation without blocking
Date: 2009-12-31 17:10:02
Message-ID: 4B3C868A020000250002DB8C@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
Greg Stark  wrote:
 
> Hm, this raises the issue that you'll have to figure out what
> should happen if two different transactions are using different
> isolation modes. Currently our two isolation modes only control
> behaviour within your transaction so they co-exist perfectly fine.
>
> ISTM you would need to have transactions in read-comitted and
> snapshot isolation modes recording what sets of records they read
> in order to be able to guarantee serializable transactions to make
> any guarantees as well.
 
No, there is no requirement that serializable transactions serialize
with weaker modes.  The Cahill thesis addresses this point directly.
Unless you can point out some flaw in his proofs, this is not an
issue.
 
> [criticisms of hypothetical implementation techniques]
 
There are no such proposals on the table, and the hypothetical
techniques you mention seem unlikely to be ones I would use.  The one
and only issue I have on the table at the moment is to create a new
lock method for SIREAD locks.  I'd welcome any comments on that.  If
I get to the point of feeling comfortable with that, I'll move
forward to other issues.
 
-Kevin


Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-12-31 17:22:45
Subject: Re: uintptr_t for Datum
Previous:From: Tom LaneDate: 2009-12-31 17:06:24
Subject: Re: Re-enabling SET ROLE in security definer functions

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