On 11/27/2013 03:52 PM, Adam Chlipala wrote:
One other change I've just pushed is inspired by the last few error messages in the Postgres-related log you showed us. These look suspiciously like optimistic concurrency faults, which should be handled by retrying transactions (as the HINTs suggest). I had already implemented checks for a few codes that I know signify such a state, but I may be missing one; so I added printing of the error code in the log messages. This means I should be able to use future logs of this kind to figure out which cases should be added to the Ur/Web Postgres code.
I looked into this further and realized that the problem was simple: There weren't any checks for concurrency faults for SELECTs; they were only there for database updates. My suspicion (or excuse?) is that Postgres never generated SELECT concurrency faults at the time I wrote the code, but they've since been added, as part of the awesome truly serializable transactions in version 9.1 and up.
I've pushed what I hope is a fix, which I haven't verified yet, since I never managed to reproduce the behavior from the benchmark error log. (As I understand the Ur/Web benchmark code, it will automatically pick up this change as part of its deployment procedure.)
_______________________________________________ Ur mailing list [email protected] http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
