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

Re: Serializable Isolation without blocking

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com>
Cc: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, "Kevin Grittner *EXTERN*" <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Serializable Isolation without blocking
Date: 2009-12-31 14:08:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Dec 31, 2009 at 12:45 PM, Nicolas Barbier
<nicolas(dot)barbier(at)gmail(dot)com> wrote:
> * To answer your specific question: T0 might not read that specific
> row, but the COUNT(..) definitely must read *something* that must be
> modified by T1 when it updates the ishighlander field:

The problem occurs when the update happens. It doesn't have any way to
know currently that a SELECT has already looked at that record and
that the same transaction has performed an update which this
transaction has already ignored when performing the count(*).

The unsolved problems that have been raised are:

- How and where do we have SELECTs note all the rows they read -- and
all the rows they *would* have read that don't exist already. Note
that something like select count(*) where id=? needs to be able to
detect new rows from being inserted with the specified value, not
merely lock the existing rows.

- Can we do it without requiring major code changes in every index am
and destroying modularity between the transaction management and the
index api.

- How do we do that without causing SELECTS to perform tons of write
i/o they don't have to do now. People already complain about the hint
bit updates the first time you do selects, doing i/o on every select
would be disastrous.

- Can we do that without destroying concurrency with course "locks" a
la MySQL ISAM tables.

- Can we do it without introducing unexpected serialization failure
between transactions updating unrelated rows. Ideally, can we do it in
a way that serialization errors are predictable rather than depending
on access paths the planner chooses so they don't just randomly start
happening when plans change.


In response to

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2009-12-31 14:20:06
Subject: Re: add xml support function
Previous:From: Kevin GrittnerDate: 2009-12-31 14:07:27
Subject: Re: A third lock method

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