From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Dan Ports <drkp(at)csail(dot)mit(dot)edu> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SSI patch version 14 |
Date: | 2011-01-27 17:18:23 |
Message-ID: | 1296148703.11513.451.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2011-01-25 at 05:57 -0500, Dan Ports wrote:
> This summary is right on. I would add one additional detail or
> clarification to the last point, which is that rather than checking for
> a cycle, we're checking for a transaction with both "in" and "out"
> conflicts, which every cycle must contain.
To clarify, this means that it will get some false positives, right?
For instance:
T1:
get snapshot
T2:
get snapshot
insert R1
commit
T1:
read R1
write R2
T3:
get snapshot
read R2
T3:
commit
T1:
commit -- throws error
T1 has a conflict out to T2, and T1 has a conflict in from T3.
T2 has a conflict in from T1.
T3 has a conflict out to T1.
T1 is canceled because it has both a conflict in and a conflict out. But
the results are the same as a serial order of execution: T3, T1, T2.
Is there a reason we can't check for a real cycle, which would let T1
succeed?
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2011-01-27 17:18:37 | Re: Spread checkpoint sync |
Previous Message | Tom Lane | 2011-01-27 17:17:02 | Upcoming back-branch updates |