[Ur] TechEmpower Benchmarks

[Adam Chlipala]

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