I think it is great that you two have reached a consensus. If Alex can
spend the time improving the tests that Leslie started along the lines
that he mentioned, I think that would be good progress for Elephant.
Thanks, gentlemen...each of these improvements makes Elephant a little
more robust.
Dear Alex,
thanks for your extensive comments on the suite.
> i have several notes about concurrent tests:
>
> 1. threaded-idx-access and provoke-deadlock are essentially same -- they
> change slot values of zork instances.
They are designed to provoke different problems, but you're right in
th
i have several notes about concurrent tests:
1. threaded-idx-access and provoke-deadlock are essentially same -- they
change slot values of zork instances.
there are some differences: threaded-idx-access runs multiple test
batches, provoke-deadlock works in one batch.
provoke-deadlock ru
> 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
> 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
> so we get
> Null store controller, default store-controller is NIL
>
> error because *store-controller* is not inherited.
Sorry, this suite isn't fully polished, yet (that's why I wanted
to have it excluded from the standard tests).
Open a store controller before running them and it'll work.
LPP> Here's the updated and rebased version of the patch, as promised.
LPP> Hopefully everything is resolved now.
this appears to be latest code, right?
(test threaded-idx-access
(dotimes (i 10)
(make-instance 'zork :slot1 i :slot2 i))
(dotimes (batch 20)
(dotimes (i 5)
(bt:m
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
LPP>>> Can you elaborate on that? Seems complicated...
??>> retry-cleanup-fn? it's actually pretty simple -- it gives application
??>> ability to hook it's code just before restarting transaction.
??>> this way application can do custom cleanup.
LPP> But how is this related to the txn isolati
> ??>> changing isolation level is dead simple, but it requires dealing with
> ??>> consequences. this was pretty hard for application i'm working with,
> ??>> so i had to make extensions like retry-cleanup-fn.
> LPP> Can you elaborate on that? Seems complicated...
>
> retry-cleanup-fn? it's a
??>> changing isolation level is dead simple, but it requires dealing with
??>> consequences. this was pretty hard for application i'm working with,
??>> so i had to make extensions like retry-cleanup-fn.
LPP> Can you elaborate on that? Seems complicated...
retry-cleanup-fn? it's actually pret
Dear Alex,
> LPP> It's a performance decision...
>
> as far as i know with MVCC higher isolation level does not cause performance
> penalties unless you really have conflicts.
> at least some postgresql experts said me this.
Sounds reasonable, yes.
> changing isolation level is dead simple, b
Dear Alex,
Thank you very much for taking the time to deal with this. I
personally don't have much of an opinion about how it should be
done---except that it sure seems like a good idea to make it
configurable, which ought to keep everybody happy, and prevents me
having to make a decision
LPP> It's a performance decision...
as far as i know with MVCC higher isolation level does not cause performance
penalties unless you really have conflicts.
at least some postgresql experts said me this.
LPP> go, but the rest of the code should try hard not to expose any
LPP> avoidable errors
The with-transaction macro passes keyword arguments to the controller-
create-transaction backend fn which you may also call directly if you
want to do something more sophisticated than wrap body code in with-
transaction.
Some examples for BDB:
dirty-read - Read written but uncommitted valu
Dear Alex:
> why would we need anything other than best isolation level?
> people might prefer "read commited" because it yields no retries, but we
> need retries anyway (in case of deadlock or duplicate pk), so i see no
> reason.
It's a performance decision... enabling the safest isolation by d
??> * handle pg error 23505 (duplicate primary key race condition)
??>>
??>> i guess race condition in plpgsql should be handled by switching to
??>> serializable transaction isolation level. (that's what i'm doing)
LPP> I don't quite see how the two of them go together.
LPP> The isolat
Dear Alex,
> i've sent reply 2 days ago -- Message-ID: <[EMAIL PROTECTED]>
Ah, I somehow missed it. Sorry.
> ??>>> * handle pg error 23505 (duplicate primary key race condition)
>
> i guess race condition in plpgsql should be handled by switching to
> serializable transaction isolation level
??>> Since Alex Mizrai is updating the postmodern code right now, are you
??>> discussing with each others about changes you make? I don't know if
??>> you work on the same things.
LPP> We are not discussing off-list right now; I'm waiting for his response
LPP> to my question on what he's wor
24 matches
Mail list logo
