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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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