Re: High rate of transaction failure with the Serializable Isolation Level

On 07/26/2014 02:58 AM, 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? :-) :-)

One can hope, but usually in vain...

> 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.

Hopefully so.

Personally I think it's moderately likely that PostgreSQL's much
stricter enforcement of serializable isolation is detecting anomalies
that other products do not, so it's potentially preventing errors.

It would be nice to have the ability to tune this; sometimes there are
anomalies you wish to ignore or permit. At present it is an all or
nothing affair - no predicate locking (REPEATABLE READ isolation) or
strict predicate locking (SERIALIZABLE isolation).

I recommend running some of the examples in the SERIALIZABLE
documentation on other products. If they don't fail where they do in Pg,
then the other products either have less strict (and arguably therefor
less correct) serialisable isolation enforcement or they rely on
blocking predicate locks. In the latter case it should be easy to tell
because statements will block on locks where no ordinary row or table
level lock could be taken.

If you do run comparative tests I would be quite interested in seeing
the results.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services