Re: A third lock method - Mailing list pgsql-hackers

From Albe Laurenz
Subject Re: A third lock method
Date
Msg-id D960CB61B694CF459DCFB4B0128514C2039380FF@exadv11.host.magwien.gv.at
Whole thread Raw
In response to Re: A third lock method  (Bruce Momjian <bruce@momjian.us>)
List 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 :^)


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: exec_execute_message crash
Next
From: fangfang liu
Date:
Subject: add xml support function