Florian Weimer wrote:
> Does SSI address the UPSERT race?
Yes, but not necessarily in the way that you would like. If all
transactions were serializable it would ensure that the UPSERT would
not commit with results inconsistent with some order of running the
UPSERT and other transactions one-at-a-time. The problem is that
when a conflict situation developed SSI would prevent an anomaly from
being persisted by killing one of the transactions involved -- and it
would likely be the transaction running the UPSERT. I get the
impression that most people interested in UPSERT would prefer a
solution which caused blocking on particular rows so that the UPSERT
would eventually make it through successfully after the other
transactions committed or rolled back.
Perhaps the predicate locking logic can be extended to allow lock
types which introduce blocking in some way which could provide the
behavior I've heard people discuss on the UPSERT threads, but the
non-blocking nature of the SIRREAD locks used by SSI only really
allows transaction cancellation as a conflict resolution technique.
-Kevin