Skip site navigation (1) Skip section navigation (2)

Re: A third lock method

From: "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "Bruce Momjian *EXTERN*" <bruce(at)momjian(dot)us>,"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A third lock method
Date: 2009-12-31 08:22:15
Message-ID: D960CB61B694CF459DCFB4B0128514C2039380FF@exadv11.host.magwien.gv.at (view raw or flat)
Thread:
Lists: pgsql-hackers
Bruce Momjian wrote:
> I must be missing something but I thought the only problem with our
> existing snapshot system was that you could see a row updated after your
> snapshot was created, and that the solution to that was to abort the
> transaction that would see the new row.  Can you tell me what I am
> missing?

But with "snapshot isolation" (what our "serializable" corresponds to)
you cannot see rows updated after snapshot creation, right?

So phantom reads cannot occur, but we still are not truly
serializable.

See the example I concocted in
http://archives.postgresql.org/pgsql-hackers/2009-05/msg00316.php
for illustration.

Yours,
Laurenz Albe

PS: Different from what Kevin claimed, Oracle also cannot grant
you strictly serializable transactions, because they also use
snapshot isolation. Seems that they get away with it.
My feeling is that the cases where this would be a problem are pretty
rare; my example referenced above feels artificial for a good reason.

If we can do it better than Oracle, I'm not against it :^)

In response to

pgsql-hackers by date

Next:From: fangfang liuDate: 2009-12-31 08:33:40
Subject: add xml support function
Previous:From: Tatsuo IshiiDate: 2009-12-31 06:56:11
Subject: Re: exec_execute_message crash

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group