Re: Serializable Isolation without blocking

From: Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com>
To: Markus Wanner <markus(at)bluegap(dot)ch>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Greg Stark <gsstark(at)mit(dot)edu>, robertmhaas(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: 2010-01-08 20:39:32
Message-ID: b0f3f5a11001081239q2ed89ee4kc08df37fb8c8955f@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2010/1/8 Markus Wanner <markus(at)bluegap(dot)ch>:

> SIREAD atop predicate locking serves detecting vulnerable edges (I hope
> I'm using that term correctly here) between newly inserted tuples and
> reads, right? I was trying to figure if it would make sense to use
> predicate locking (instead of table or row level locking) as well for
> detecting vulnerable edges between updated or deleted tuples and reads.

AFAICS, detecting a "rw" dependency where the read executes after the
write is rather easy: the writer has created a row version that is not
visible to the reader's snapshot. Therefore, any time a reader reads a
non-last version of a row, there is a rw dependency between it and the
creators of any newer versions.

Btw, rw dependencies are the only thing that needs to be checked under
SI, as "wr" and "ww" dependencies never lead to problems: one can only
see (or update) a certain row version using a transaction that has
taken its snapshot after the writing transaction already committed.
Therefore, the "must be before" relationship between such transactions
is trivially satisfied. (I assume here that PG's non-SI-compatible
behavior of not always rollbacking any transaction that writes to a
non-last version will be disabled in serializable mode.)

Nicolas

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2010-01-08 20:43:33 Re: damage control mode
Previous Message Josh Berkus 2010-01-08 20:28:08 Re: damage control mode