4 ms·

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 ups

• opendomain 11y ago
  You can fix this with basic SQL IF record EXISTS then UPDATE else INSERT
  • anarazel 11y ago
    No. Conccurrency makes it way harder than that.
    • devit 11y ago
      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 11y ago
        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 11y ago
        Use UPSERT, it's correct -and- fast rather than just correct. Increasing the transaction isolation level shouldn't be done out of laziness.