Re: Serializable Isolation without blocking - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Serializable Isolation without blocking
Date
Msg-id 87ocu5urpz.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Serializable Isolation without blocking  ("Albe Laurenz" <laurenz.albe@wien.gv.at>)
Responses Re: Serializable Isolation without blocking  ("Albe Laurenz" <laurenz.albe@wien.gv.at>)
Re: Serializable Isolation without blocking  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
"Albe Laurenz" <laurenz.albe@wien.gv.at> writes:

> So I think one would have to add intention locks for rows considered
> in the WHERE clause to guarantee true serializability.

Does the paper explain how to deal with rows "considered" in the WHERE clause
which don't yet exist? Ie, "SELECT count(*) WHERE foo" needs to take out a
lock which would cause any transaction which inserts a new record where foo is
true to be abort.

In MSSQL this requires locking the page of the index where such records would
be inserted (or the entire table if there's no index). In Predicate locking
schemes this requires a separate storage structure for storing such predicates
which can be arbitrarily complex expressions to check any new tuple being
inserted against.

Are these intention locks predicate locks, in that they're not associated with
actual pages or records but with potential records which might be inserted in
the future?

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!


pgsql-hackers by date:

Previous
From: Michael Meskes
Date:
Subject: Re: ECPG, two varchars with same name on same line
Next
From: Andres Freund
Date:
Subject: Re: conditional dropping of columns/constraints