[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