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@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
