[elephant-devel] Re: Updated version of last Postmodern patch bundle

Leslie P. Polzer leslie.polzer at gmx.net
Wed Mar 19 18:59:56 UTC 2008


> aha, so you mean we need retries anyway?

We might. I'm not sure because I'm still not fully into the stuff you
are doing.


> if simple slot writes provoke deadlocks that is not OK IMHO. PostgreSQL
> documentation
> (http://www.postgresql.org/docs/8.1/static/explicit-locking.html#LOCKING-DEADLOCKS)
> mentions several resasons why deadlocking can happen, and it doesn't look
> like we are triggering one of them explicitly.
> so chances are this can be fixed via some modifications of the code.

That's all good, but I have a real problem with the stance of saying
“let there be good code and we'll have no deadlocks” because the problem
whether code is good is undecidable.

So I'm for a solution that is as elegant and efficient as possible
but will also handle deadlocks if they occur.


> as far as i know deadlocks are much worse than conflicts performance-wise --
> because they are detected by the timer, something like once a second, unlike
> conflicts that are detected immidiately -- and we should try making them
> impossible in working course of operations.

That's right. The txn dependency graph will have to be check for cycles
regularly.


> retries due to conflicts are totally different -- whole txn retry must be
> triggered according to txn semantics, it cannot be done transparently, and
> application can be impacted if it's code is not side-effect-less.

Shouldn't the application programmer always anticipate a transaction abort?


> e.g. braindead solution -- before writing, lock whole table so nobody can
> write concurrently (but still can read) -- this way we can be sure that
> there will be no race conditions, but this will also have considerable
> performance impact.

Yeah, that's the MySQL solution. I'm against it :)


> probably there is some better way to do this.. maybe SELECT FOR UPDATE will
> do.. but first i need to investigate what really happens there

Thanks, I'll leave this to you for the time being...

  Leslie





More information about the elephant-devel mailing list