Re: User-facing aspects of serializable transactions

From: Greg Stark <stark(at)enterprisedb(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "<Markus Wanner" <markus(at)bluegap(dot)ch>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, "<pgsql-hackers(at)postgresql(dot)org>" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: User-facing aspects of serializable transactions
Date: 2009-06-01 21:12:48
Message-ID: 4136ffa0906011412i12cbd828sbf2c81eae4616760@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 1, 2009 at 9:24 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> I'm concerned with whether you can be sure that the 999th time you
>> run it the database won't randomly decide to declare a serialization
>> failure for reasons you couldn't predict were possible.
>
> Now you're questioning whether SERIALIZABLE transaction isolation
> level is useful.  Probably not for everyone, but definitely for some.

No, I'm not. I'm questioning whether a serializable transaction
isolation level that makes no guarantee that it won't fire spuriously
is useful.

Postgres doesn't take block level locks or table level locks to do
row-level operations. You can write code and know that it's safe from
deadlocks.

Heikki proposed a list of requirements which included a requirement
that you not get spurious serialization failures and you rejected that
on the basis that that's not how MSSQL and Sybase implement it.

I'm unhappy with the idea that if I access too many rows or my query
conditions aren't written just so then the database will forget which
rows I'm actually concerned with and "lock" other random unrelated
records and possibly roll my transaction back even though my I had no
way of knowing my code was at risk.

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2009-06-01 21:17:30 Re: Suggested TODO: allow ALTERing of typemods without heap/index rebuild
Previous Message Jeff Davis 2009-06-01 20:49:48 Re: Suggested TODO: allow ALTERing of typemods without heap/index rebuild