From: Ryan Johnson <ryan.johnson@cs.utoronto.ca>
To: pgsql-performance@postgresql.org
Subject: Re: High rate of transaction failure with the Serializable Isolation Level
Date: Fri, 25 Jul 2014 17:35:31 -0400
Message-ID: <53D2CDA3.8050707@cs.utoronto.ca> (raw)
In-Reply-To: <80d78b6fec064f14aa025c1ca86c8099@EX13-MBX-013.vmware.com>
References: <ded604822b28427a80b0751a973e4258@EX13-MBX-013.vmware.com>
<53D0923B.7050501@2ndquadrant.com>
<93e2642196e646adbcf5780d3cf54685@EX13-MBX-013.vmware.com>
<53D1B31B.8070909@2ndquadrant.com>
<80d78b6fec064f14aa025c1ca86c8099@EX13-MBX-013.vmware.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
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://github.com/petergeoghegan/dbt5
Ryan
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: ryan.johnson@cs.utoronto.ca
Subject: Re: High rate of transaction failure with the Serializable Isolation Level
In-Reply-To: <53D2CDA3.8050707@cs.utoronto.ca>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox