On Tue, Sep 21, 2010 at 12:57 PM, Kevin Grittner
wrote:
>> What is the likelyhood that there exists an update pattern that
>> always give the failure in the slow transaction ?
>
> I don't know how to quantify that. I haven't seen it yet in
> testing, but many of my tests so far have been rather c
Dan S wrote:
> A starvation scenario is what worries me:
>
> Lets say we have a slow complex transaction with many tables
> involved. Concurrently smaller transactions begins and commits .
>
> Wouldn't it be possible for a starvation scenario where the slower
> transaction will never run to c
A starvation scenario is what worries me:
Lets say we have a slow complex transaction with many tables involved.
Concurrently smaller transactions begins and commits .
Wouldn't it be possible for a starvation scenario where the slower
transaction will
never run to completion but give a serializat
Dan S wrote:
> Well I guess one would like some way to find out which statements
> in the involved transactions are the cause of the serialization
> failure and what programs they reside in.
Unless we get the conflict list optimization added after the base
patch, you might get anywhere from on
Well I guess one would like some way to find out which statements in the
involved transactions are the cause of the serialization failure and what
programs they reside in.
Also which relations were involved, the sql-statements may contain many
relations but just one or a few might be involved in t
Dan S wrote:
> I wonder if the SSI implementation will give some way of detecting
> the cause of a serialization failure.
> Something like the deadlock detection maybe where you get the
> sql-statements involved.
I've been wondering what detail to try to include. There will often
be three tra
