[elephant-devel] Re: Updated version of last Postmodern patch bundle
Leslie P. Polzer
leslie.polzer at gmx.net
Tue Mar 18 14:48:06 UTC 2008
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
More information about the elephant-devel
mailing list