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

[Alex Mizrahi]

 ??>> 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