Re: BUG #11732: Non-serializable outcomes under serializable isolation - Mailing list pgsql-bugs

From Kevin Grittner
Subject Re: BUG #11732: Non-serializable outcomes under serializable isolation
Date
Msg-id 1414501779.7484.YahooMailNeo@web122306.mail.ne1.yahoo.com
Whole thread Raw
In response to Re: BUG #11732: Non-serializable outcomes under serializable isolation  (Peter Bailis <pbailis@cs.berkeley.edu>)
Responses Re: BUG #11732: Non-serializable outcomes under serializable isolation  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-bugs
Peter Bailis <pbailis@cs.berkeley.edu> wrote:

> Have you had any luck reproducing this behavior?

Yes I have.  I was able to create it using just plpgsql and psql
with a bash script.  Using that technique I was able to create the
problem without the RETURNING clause and with a streamlining of
the function you suggested.  With an int column instead of a
character-based column I have (so far) not been able to trigger it.

I have confirmed that this bug goes all the way back to the
introduction of the Serializable Snapshot Isolation technique in
9.1.

Everything suggests a race condition.  I haven't been able to pin
down exactly where it happens, but that's just a matter of time.
It is interesting that the data type of the column changes the
timing enough to have such a large effect on seeing the failure.
I've set it aside for the moment but expect to get back to it later
this week.

Thanks for bringing this to our attention, complete with a
reproducible test case!

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

pgsql-bugs by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: ltree::text not immutable?
Next
From: bzhao@recognia.com
Date:
Subject: BUG #11807: Postgresql server crashed when running transaction tests