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
|
Список | 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 по дате отправления: