Re: Serializable Isolation without blocking

Поиск
Список
Период
Сортировка
От Albe Laurenz
Тема Re: Serializable Isolation without blocking
Дата
Msg-id D960CB61B694CF459DCFB4B0128514C202FF65B0@exadv11.host.magwien.gv.at
обсуждение исходный текст
Ответ на Re: Serializable Isolation without blocking  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-hackers
Greg Stark wrote:
> > 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.

Quote:
"To prevent phantoms in a system with row-level locking and versioning,
the algorithm described here would need to be extended to take SIREAD locks
on larger granules analogously to multigranularity intention locks in
traditional two-phase locking systems."

[...]

"We have not pursued the details in this paper because the phantom
issue does not arise in our prototype implementation, since Oracle
Berkeley DB does all locking and versioning at page granularity."

End quote.

> 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?

No, they are associated with the page that contains the actual record.

I think that's also meant with the "larger granules" in the above quote:
Take an intention lock on every page which might affect the condition.

Yours,
Laurenz Albe


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: [BUGS] BUG #4796: Recovery followed by backup creates unrecoverable WAL-file
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Extra cost of "lossy mode" Bitmap Scan plan