[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