On 03.06.2011 00:14, Kevin Grittner wrote:
Attached is a comments-only patch for this, along with one
correction to the comments you added and a couple other typos.
Ok, committed.
I'll submit a patch for the README-SSI file once I find a reference
I like to a paper describing what Dan's proo
On Thu, Jun 02, 2011 at 01:01:05PM -0500, Kevin Grittner wrote:
> If we're going to put this into the README-SSI as the proof of the
> validity of this optimization, I'd like to have a footnote pointing
> to a paper describing the "first commit in the cycle" aspect of a
> dangerous structure. Got
Heikki Linnakangas wrote:
> On 30.05.2011 17:10, Kevin Grittner wrote:
>> Heikki Linnakangas wrote:
>>> * XXX: for an anomaly to occur, T2 must've committed
>>> * before W. Couldn't we easily check that here, or does
>>> * the fact that W committed already somehow imply it?
>>
Dan Ports wrote:
> On Wed, Jun 01, 2011 at 05:09:09PM -0500, Kevin Grittner wrote:
>> Published papers have further proven that the transaction which
>> appears to have executed last of these three must actually commit
>> before either of the others for an anomaly to occur.
>
> We can actually
On Wed, Jun 01, 2011 at 05:09:09PM -0500, Kevin Grittner wrote:
> I won't be shocked if Dan can come up with a shorter proof, but I'm
> confident this one is solid.
Well, so happens I wrote a proof on the airplane today, before I saw
your mail. It's actually quite straightforward... (well, at leas
Heikki Linnakangas wrote:
> On 30.05.2011 17:10, Kevin Grittner wrote:
>> This optimization is an original one, not yet appearing in any
>> academic papers; Dan and I are both convinced it is safe, and in
>> off-list correspondence with Michael Cahill after he left Oracle,
>> he said that he dis
On 30.05.2011 17:10, Kevin Grittner wrote:
Heikki Linnakangas wrote:
On 26.05.2011 06:19, Kevin Grittner wrote:
I did some of that in the comments, and I think I understand it
now. See attached patch. Does that look right to you?
! * A serialization failure can only occur if there is a danger
On 26.05.2011 06:19, Kevin Grittner wrote:
/*
* Check whether the writer has become a pivot with an out-conflict
* committed transaction, while neither reader nor writer is committed.
If
* the reader is a READ ONLY transaction, there is only a serialization
[The first attempt to send this shows as undeliverable to the list.
Resending for completeness and coherency of archives. Apologies to
those getting duplicates.]
> Heikki Linnakangas wrote:
> On 26.05.2011 06:19, Kevin Grittner wrote:
>
>> /*
>> * Check whether the writer has become a pivot wit
Heikki Linnakangas wrote:
> Could you explain in the README, why it is safe to only take the
> lock on the visible row version, please?
Sure. I actually intended to do this last night but ran out of
steam and posted what I had, planning on following up with that.
The place it seemed to fit
On 26.05.2011 06:19, Kevin Grittner wrote:
Dan and I went around a couple times chasing down all code, comment,
and patch changes needed, resulting in the attached patch. We found
and fixed the bug which originally manifested in a way which I
confused with a need for row locks, as well as anothe
> Dan Ports wrote:
> On Tue, May 24, 2011 at 04:18:37AM -0500, Kevin Grittner wrote:
>> These proofs show that there is no legitimate cycle which could
>> cause an anomaly which the move from row-based to tuple-based
>> logic will miss. They don't prove that the change will generate
>> all the s
On Tue, May 24, 2011 at 04:18:37AM -0500, Kevin Grittner wrote:
> These proofs show that
> there is no legitimate cycle which could cause an anomaly which the
> move from row-based to tuple-based logic will miss. They don't prove
> that the change will generate all the same serialization failures;
"Kevin Grittner" wrote:
> Dan Ports wrote:
>> Does that make sense to you?
>
> Makes sense to me. Like the proof I offered, you have shown that
> there is no cycle which can develop with the locks copied which
> isn't there anyway if we don't copy the locks.
I woke up with the nagging though
Dan Ports wrote:
> [I think it's similar to the argument you were making.]
Similar, but you found a simpler, shorter way to the end, which
should make Robert happy. ;-)
> On Sat, May 21, 2011 at 03:09:12PM -0500, Kevin Grittner wrote:
>> The issue can be rephrased to this: If transaction T1
I have thought about this quite a bit and am fairly certain we do not need
to track this linkage between row versions. One strong hint to this
is that all the work I've seen on multiversion serializability
theory defines a rw-conflict to be one transaction reading an object
and the other writing *t
Dan Ports wrote:
> Specifically, the problem is a missing check in
> OnConflict_CheckForSerializationFailure. We check whether the
> conflict has caused the writer to become a pivot, but only if
> neither the reader or writer is committed. Why is that last
> condition there? In this case, the re
Dan Ports wrote:
> On Sat, May 21, 2011 at 03:09:12PM -0500, Kevin Grittner wrote:
>> I went back to the example which persuaded me and took another
>> look. On review I see that this didn't prove the point because
>> there was a dangerous structure with T1 as a pivot which should
>> have caused
On Sat, May 21, 2011 at 03:09:12PM -0500, Kevin Grittner wrote:
> I went back to the example which persuaded me and took another look. On
> review I see that this didn't prove the point because there was a
> dangerous structure with T1 as a pivot which should have caused SSI to
> break the cycle.
Robert Haas wrote:
> The point I was driving at is - in what way will that affect the
> behavior of subsequent operations?
You haven't answered why you think it should matter for OID or for
write conflict on READ COMMITTED but not here. The logical concept
of a row which is modified is a mean
On Mon, May 23, 2011 at 10:20 AM, Tom Lane wrote:
> Aidan Van Dyk writes:
>> So, if SSI conflicts something on the UPDATE case, it would necessrily
>> have to conflict the DELETE+INSERT case as well, and vice-versa.
>
> This argument is fundamentally bogus, because an UPDATE is not the same
> thi
Aidan Van Dyk writes:
> So, if SSI conflicts something on the UPDATE case, it would necessrily
> have to conflict the DELETE+INSERT case as well, and vice-versa.
This argument is fundamentally bogus, because an UPDATE is not the same
thing as DELETE followed by INSERT. In the former case the new
On Mon, May 23, 2011 at 2:26 AM, Kevin Grittner
wrote:
> I don't see that -- it could be correct because of the conceptual
> difference between an UPDATE and a DELETE/INSERT pair.
>
>> In other words, if SSI needs to be more rigorous in the UPDATE
>> case, it can only be because snapshot isolati
Robert Haas wrote:
> I think the implementation is what matters here. I understand that
> there are certain situations in which the user might choose to
> UPDATE a row and other situations in which they might choose to
> DELETE and then INSERT: but the user's intent is basically
> irrelevant.
On Sat, May 21, 2011 at 8:50 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> How is an UPDATE different from a DELETE and an INSERT?
>
> That's the question Jeff asked which caused us to revisit this.
>
> There are two answers -- conceptual and implementation.
>
> Conceptually, an updated row i
Robert Haas wrote:
> How is an UPDATE different from a DELETE and an INSERT?
That's the question Jeff asked which caused us to revisit this.
There are two answers -- conceptual and implementation.
Conceptually, an updated row is the same row, and a row inserted after a
delete is a new row.
On Sat, May 21, 2011 at 4:09 PM, Kevin Grittner
wrote:
> [Anyone who has followed along this far has earned my undying
> gratitude.]
>
> Since the chain of transactions has to overlap T0 and T3, I don't see
> how that can happen. We established that T0 has to commit before T3 can
> start, so the
On Sat, May 21, 2011 at 04:45:15PM -0400, Pavan Deolasee wrote:
> As a first step, it would be great if you can upload the slides on the
> conference website. To expect that the attendees would have understood the
> nitty-gritties of SSI just listening to the presentation is so unhuman :-)
I just
Pavan Deolasee wrote:
> As a first step, it would be great if you can upload the slides on
> the conference website. To expect that the attendees would have
> understood the nitty-gritties of SSI just listening to the
> presentation is so unhuman :-)
I'm sure Dan will be doing that soon; meanw
On Sat, May 21, 2011 at 4:09 PM, Kevin Grittner wrote:
>
> It would be great if anyone with a grasp
> of SSI concepts could confirm its validity or shoot it down. (Hopefully
> Friday's presentation expanded the number of those who can do so.)
>
>
As a first step, it would be great if you can upl
As background, for most of SSI development I had a TODO comment in the
source which was basically around the question of whether a predicate
lock on a visible heap tuple should propagate to later versions of the
row as long as the original lock was material. In early February Heikki
(quite reasona
31 matches
Mail list logo
