Re: BUG #11732: Non-serializable outcomes under serializable isolation
От | Kevin Grittner |
---|---|
Тема | Re: BUG #11732: Non-serializable outcomes under serializable isolation |
Дата | |
Msg-id | 1414501779.7484.YahooMailNeo@web122306.mail.ne1.yahoo.com обсуждение исходный текст |
Ответ на | Re: BUG #11732: Non-serializable outcomes under serializable isolation (Peter Bailis <pbailis@cs.berkeley.edu>) |
Ответы |
Re: BUG #11732: Non-serializable outcomes under serializable
isolation
|
Список | 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 по дате отправления: