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

[Ian Eslick]

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 than before

Ian

On Mar 19, 2008, at 12:26 PM, Ian Eslick wrote:
> 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
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel