I wrote:
> It's just a little bit of a stretch to call SILOCKs locks, because
> they don't actually block anything. They are used at various points
> to see where a transaction is reading data which has been modified
> by another transaction or vice versa. And they do need to be kept
> until all
"Albe Laurenz" wrote:
> 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.
My previous reply missed your point entirely, didn't it?
L
"Albe Laurenz" wrote:
> See the example I concocted in
> http://archives.postgresql.org/pgsql-hackers/2009-05/msg00316.php
Sure, let's look at that example. Of course, *any* transaction run
by itself won't show differences from true serializable behavior
*regardless* of the mode in which it ru
2009/12/31 Bruce Momjian :
> 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
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 wha
Kevin Grittner wrote:
> Once I sort out the subject issue, I'm about ready to try to start
> generating a very rough prototype of predicate locking. I don't want
> to start a discussion of those details on this thread, because it
> seems to me that a decision on the subject issue affects significa
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
Kevin Grittner wrote:
> I've been reviewing code to get a better handle on the scope of
> changes to support serializable transactions, in preparation for
> next month's meetings with our CIO. My posts should start getting
> progressively less hand-wavy. :-)
>
> I've come to a few conclusions:
I've been reviewing code to get a better handle on the scope of
changes to support serializable transactions, in preparation for
next month's meetings with our CIO. My posts should start getting
progressively less hand-wavy. :-)
I've come to a few conclusions:
(1) The notions of having multi
