[elephant-devel] Re: Updated version of last Postmodern patch bundle

[Ian Eslick]

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.  I was careful to add ensure-transaction  
wrappers around everything so that would be the case, but it's  
certainly possible I missed some path.

I'd love to see a reproducible deadlock test, even if it had to run  
for awhile.

Cheers,
Ian

On Mar 19, 2008, at 12:17 PM, Alex Mizrahi wrote:
> ??>> 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.
> LPP> In general it seems to be a tough bet relying on this.
>
> aha, so you mean we need retries anyway?
> i did not look into tests source code and thought that you're  
> provoking them
> in "traditional" way.
>
> 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.
>
> 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.
>
> if you have an idea how our code can trigger situation as described  
> in pgsql
> manual please drop a note.
>
> ??>> also, we have a race condition in update-or-insert  
> implementation, but
> ??>> this could be avoided either via savepoints,
>
> LPP> But SPs are just a way to have more fine-grained retries, so it's
> LPP> not really different from retrying the whole txn...
>
> no, for our purposes savepoints just alter error handling policy of  
> pgsql.
> such retries can be implemented in a stored procedure code, totally
> transparent from lisp side,
> or in db-postmodern code, totally transparent from application.
>
> 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.
>
> ??>> or via locking.
>
> LPP> pgsql automatically locks, doesn't it?
>
> implicitly it obtains only "minimal" locks. knowing semantics of  
> operations,
> we can explicitly deman stricter locking, and this way avoid  
> deadlocks or
> race conditions.
> 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.
> 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
>
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel