On Thursday, October 8, 2015 5:01 AM, "sean@chittenden.org" <sean@chittenden.org> wrote:
> A few weeks back I was pointed in the direction of a bug that appears to be
> an SSI violation. The repro case below is written using bash and psql.
>
> In a tight loop, we would expect 50% of these transactions to fail.
> Instead, periodically we're seeing both transaction commit successfully.
> The concern is that PostgreSQL thinks these transactions are commutable or
> the SIREAD lock isn't erected correctly.
>
> https://github.com/gfredericks/pg-serializability-bug
>
> The two concurrent transactions required to tickle this bug are:
>
> BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
> INSERT INTO things (id) VALUES ('A');
> SELECT id FROM things;
> COMMIT;
>
> BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
> INSERT INTO things (id) VALUES ('B');
> SELECT id FROM things;
> COMMIT;
I agree this is a bug, and it behave like a race condition with a
very narrow window of time for the second process to hit. It has
proven very hard to find the cause. So far every attempt to
instrument the code to catch the bug in progress has distorted the
timings enough to prevent the bug from showing. Next time I take a
run at this I think I need to insert delays at suspicious points in
the code to try to provoke it at greater volume. If anyone else
wants to take a shot at that and show me what they found that does
that, it would expedite getting a fix.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company