From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Serializable snapshot isolation patch |
Date: | 2010-10-21 16:47:49 |
Message-ID: | 1287679669.8516.618.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2010-10-21 at 10:29 -0500, Kevin Grittner wrote:
> Basically, when we already have a pivot, but no transaction has yet
> committed, we wait to see if TN commits first. If so, we have a
> problem; if not, we don't. There's probably some room for improving
> performance by cancelling T0 or T1 instead of TN, at least some of
> the time; but in this pass we are always cancelling the transaction
> in whose process we detect the need to cancel something.
Well, in this case we do clearly have a problem, because the result is
not equal to the serial execution of the transactions in either order.
So the question is: at what point is the logic wrong? It's either:
1. PreCommit_CheckForSerializationFailure() is missing a failure case.
2. The state prior to entering that function (which I believe I
sufficiently described) is wrong.
If it's (2), then what should the state look like, and how is the GiST
code supposed to result in that state?
I know some of these questions are answered in the relevant research,
but I'd like to discuss this concrete example specifically.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2010-10-21 17:11:24 | Re: Domains versus arrays versus typmods |
Previous Message | Tom Lane | 2010-10-21 16:46:39 | Re: Domains versus arrays versus typmods |