Hello Alex, I had a hard time understanding the point of your message, so it'll probably need a little more discussion until I get it. But anyway:
> retry handling was not implemented because there was very little need for > retries in absense of concurrent conflicts (pgsql does not signal those > conflicts if you're using default read commited isolation level). What do you mean by “signal”? It aborts the whole transaction when a conflict (deadlock, violation of uniqueness, ...) is detected. > theoretically we could get a deadlock, but it only happens if application > updates object in different order, and this can be avoided. Note that concurrent writes to an indexed slot will currently have a pretty high chance of inducing a deadlock. Try the new test suite. In general it seems to be a tough bet relying on this. > also, we have a race condition in update-or-insert implementation, but this > could be avoided either via savepoints, But SPs are just a way to have more fine-grained retries, so it's not really different from retrying the whole txn... > or via locking. pgsql automatically locks, doesn't it? > so, we could live without transaction retrying unless we really need > serializable isolation level. But in read-commited mode the errors that come up require restarting the transaction. Why do you say we can live without retrying then? Leslie _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
