[buhrmi]

I'm using upserts... The reason I'm using upserts is basically just lazyness because I didn't feel like refactoring the source code to work around requiring upserts. Also, I'm not very confident in C++ so I did not want to take on that task.

[opendomain]

You can fix this with basic SQL

IF record EXISTS then UPDATE else INSERT

[anarazel]

No. Conccurrency makes it way harder than that.

[devit]

In PostgreSQL, you can set the SERIALIZABLE isolation level for the whole database, put a retry loop around all database transactions and completely stop worrying about concurrency issues.

I think all database applications should be written like this at least until performance starts being an issue.

[anarazel]

Entirely depends on the the type of workload / application architecture. In some cases the rollback ratios will be massive (I've seen 70%). In other cases adding such a retry loop is unattractive because the latency jitter. Or retaining all involved data for a retry is unattrictive.

Yet Another problem is that you need to enforce all sessions potentially involved in a data race need to use serializable; that can be easy or hard, depending on the scenario.

[jpgvm]

Use UPSERT, it's correct -and- fast rather than just correct.

Increasing the transaction isolation level shouldn't be done out of laziness.