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

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Florian Pflug" <fgp(at)phlo(dot)org>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle
Date: 2010-05-14 14:32:32
Message-ID: 4BED18B0020000250003172D@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Florian Pflug <fgp(at)phlo(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc G. Fournier 2010-05-14 14:38:39 Re: List traffic
Previous Message Robert Haas 2010-05-14 14:26:15 Re: List traffic