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
> 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.
> 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.
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
> ??>> 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
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
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
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
15 matches
Mail list logo
