> 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
