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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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