Re: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle
Дата
Msg-id 4BED18B0020000250003172D@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle  (Florian Pflug <fgp@phlo.org>)
Ответы Re: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle  (Rob Wultsch <wultsch@gmail.com>)
Список pgsql-hackers
Florian Pflug <fgp@phlo.org> wrote:
> I must admit that I wasn't able to find an explicit reference to
> Oracle's behavior in their docs, so I had to resort to
> experiments. They do have examples showing how to do FK-like
> constraints with triggers, and those don't contain any warning
> whatsoever about problems in SERIALIZABLE mode, though.  But
> still, if there is word on this from Oracle somewhere, I'd love to
> hear about it.
I suspect that in trying to emulate Oracle on this, you may run into
an issue which posed challenges for the SSI implementation which
didn't come up in the Cahill prototype implementations: Oracle, and
all other MVCC databases I've read about outside of PostgreSQL, use
an "update in place with a rollback log" technique.  Access to any
version of a given row or index entry goes through a single
location, with possible backtracking through the log after that,
which simplifies management of certain concurrency issues.  Do they
perhaps use an in-RAM lock table, pointing to the "base" location of
the row for these SELECT FOR UPDATE locks?  (Just guessing; I've
never used Oracle, myself.)
-Kevin


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

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: List traffic
Следующее
От: "Marc G. Fournier"
Дата:
Сообщение: Re: List traffic