3 ms·
I think his point is quite exactly that a concurrent write transaction (starts after the first transaction starts but before it commits) that relies on the exis
by nuclear_eclipse 13y ago
I think his point is quite exactly that a concurrent write transaction (starts after the first transaction starts but before it commits) that relies on the existence of that key/value pair will fail because of how Postgres works.
- PeterisP 13y agoOK, I tried this on a random PG server I had and replicated the issue with a concurrent update; and running two such transactions in 'overlapping' way inserted two duplicate entries for the same key. That is interesting - is the current behavior really considered WAD? I.e., shouldn't then the 'correct' solution be in fixing this behavior instead of extending syntax for 'upserts'?
- jeltz 13y agoYes, but he is wrong about isolation levels. At serializable you will get a serilization conflict.