Re: High rate of transaction failure with the Serializable Isolation Level - Mailing list pgsql-performance

Hi Ryan,
That's a very good point. We are looking at dbt5. One question: what throughput rate, and how many threads of execution
didyou use for dbt5?  The failure rates I reported were at ~120 tps with 15 trade-result threads. 

Thanks,
Reza

> -----Original Message-----
> From: pgsql-performance-owner@postgresql.org [mailto:pgsql-
> performance-owner@postgresql.org] On Behalf Of Ryan Johnson
> Sent: Friday, July 25, 2014 2:36 PM
> To: pgsql-performance@postgresql.org
> Subject: Re: High rate of transaction failure with the Serializable Isolation
> Level
>
> On 25/07/2014 2:58 PM, Reza Taheri wrote:
> > Hi Craig,
> >
> >> According to the attached SQL, each frame is a separate phase in the
> operation and performs many different operations.
> >> There's a *lot* going on here, so identifying possible
> >> interdependencies isn't something I can do in a ten minute skim read over
> my morning coffee.
> > You didn't think I was going to bug you all with a trivial problem,
> > did you? :-) :-)
> >
> > Yes, I am going to have to take an axe to the code and see what pops out.
> Just to put this in perspective, the transaction flow and its statements are
> borrowed verbatim from the TPC-E benchmark. There have been dozens of
> TPC-E disclosures with MS SQL Server, and there are Oracle and DB2 kits that,
> although not used in public disclosures for various non-technical reasons, are
> used internally in by the DB and server companies. These 3 products, and
> perhaps more, were used extensively in the prototyping phase of TPC-E.
> >
> > So, my hope is that if there is a "previously unidentified interdependency
> between transactions" as you point out, it will be due to a mistake we made
> in coding this for PGSQL. Otherwise, we will have a hard time convincing all
> the council member companies that we need to change the schema or the
> business logic to make the kit work with PGSQL.
> >
> > Just pointing out my uphill battle!!
> You might compare against dbt-5 [1], just to see if the same problem occurs. I
> didn't notice such high abort rates when I ran that workload a few weeks
> ago. Just make sure to use the latest commit, because the "released" version
> has fatal bugs.
>
> [1]
> https://urldefense.proofpoint.com/v1/url?u=https://github.com/petergeog
> hegan/dbt5&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=b9TKmA0CPjr
> oD2HLPTHU27nI9PJr8wgKO2rU9QZyZZU%3D%0A&m=6E%2F9fWJPMGjpMyP
> xtY0nsamLLW%2FNsTXu7FP9Wzauj10%3D%0A&s=b3f269216d419410f3f07bb
> 774a27b7d377744c9d423df52a3e62324d9279958
>
> Ryan
>
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> https://urldefense.proofpoint.com/v1/url?u=http://www.postgresql.org/m
> ailpref/pgsql-
> performance&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=b9TKmA0CP
> jroD2HLPTHU27nI9PJr8wgKO2rU9QZyZZU%3D%0A&m=6E%2F9fWJPMGjpMy
> PxtY0nsamLLW%2FNsTXu7FP9Wzauj10%3D%0A&s=45ab94ce068dbe28956af
> 8bb3f999e9a91138dd1e3c3345c036e87e902da1ef1