Re: Serializable Isolation without blocking

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: Serializable Isolation without blocking
Дата
Msg-id 87ocu5urpz.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: Serializable Isolation without blocking  ("Albe Laurenz" <laurenz.albe@wien.gv.at>)
Ответы Re: Serializable Isolation without blocking  ("Albe Laurenz" <laurenz.albe@wien.gv.at>)
Re: Serializable Isolation without blocking  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список 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 по дате отправления:

Предыдущее
От: Michael Meskes
Дата:
Сообщение: Re: ECPG, two varchars with same name on same line
Следующее
От: Andres Freund
Дата:
Сообщение: Re: conditional dropping of columns/constraints