Great! Actually in writing the following e-mail, I realized that this
had forced me to think through a bunch of things and so I wrote a
version of the functionality in associations.lisp and just checked it
in.
Start playing with, reading and commenting on what's wrong with it.
For examp
I just wasn't following this discussion closely enough. I'll work
with that test when I get a chance.
Ian
On Mar 19, 2008, at 2:52 PM, Alex Mizrahi wrote:
IE> may be less of an issue in the past. Deadlock is certainly
likely to
IE> happen if the set of operations to update an indexed slot
> 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-DEADLO
IE> may be less of an issue in the past. Deadlock is certainly likely to
IE> happen if the set of operations to update an indexed slot is not
IE> wrapped in a transaction.
can you explain why?
as i understand deadlocks can happen when there are two or less locks in
both concurrent transaction
> I'd love to see a reproducible deadlock test, even if it had to run
> for awhile.
I may have misunderstood you, but the PROVOKE-DEADLOCK test does just
this and leads to deadlocks quickly.
Leslie
___
elephant-devel site list
elephant-devel@common-
> ok, but it was not excluded (probably if you do not write in-suite it
> appends tests into prev suite)
> and it confused me quite a lot, because i did not know where errors are
> coming from.
Sorry; the original patch put the thing in a separate suite (which works
correctly by itself) but also
To clarify my bad language...
1) It's possible I currently miss an ensure-transaction on some path
while writing the index
2) I'd love to see a test that reproduced the current deadlock, even
if it ran a long time
3) Indexed slot access should become simpler - less potential for
deadlock th
Slot access to indexed slots are somewhat hairy at present.
I think they are much simpler in the unstable branch and so deadlock
may be less of an issue in the past. Deadlock is certainly likely to
happen if the set of operations to update an indexed slot is not
wrapped in a transaction.
??>> theoretically we could get a deadlock, but it only happens if
??>> application updates object in different order, and this can be
??>> avoided.
LPP> Note that concurrent writes to an indexed slot will currently have
LPP> a pretty high chance of inducing a deadlock. Try the new test suite
??>> so we get
??>> Null store controller, default store-controller is NIL
??>>
??>> error because *store-controller* is not inherited.
LPP> Sorry, this suite isn't fully polished, yet (that's why I wanted
LPP> to have it excluded from the standard tests).
ok, but it was not excluded (prob
Hi Ian,
My best guess is weeks, not months. We're hoping for April sometime,
but it depends on a number of factors. Elephant is getting quite
complex to test so the last few bugs can take some time.
You can speed this process up if you want to help develop and test the
association facilit
11 matches
Mail list logo
