Re: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle
Date
Msg-id 4BED18B0020000250003172D@gw.wicourts.gov
Whole thread Raw
In response to Re: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle  (Florian Pflug <fgp@phlo.org>)
Responses Re: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle
List 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 by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: List traffic
Next
From: "Marc G. Fournier"
Date:
Subject: Re: List traffic