Tom Lane wrote:> I can't see a reason for bare UPDATEs of that sort to get deadlocks.> There must be some other factor
involved. Do you have triggers, rules,> or foreign keys on this table? Other locks being taken in the same>
transaction?
We haven't finished implementing our transaction system yet, so no,
there are no other things running in the txn. Each of those statements
is a complete txn. <blush>
This problem only happens on our production server (Murphy's Law). I
haven't been able to duplicate it on our test system. The production
system is a heavily multi-threaded environment that has lots of data
entering the system all the time. This makes it difficult to detect
which SQL statements are affecting each other. :(
There are no triggers or rules except for the foreign keys.
The txn table has several foreign keys. The two that seem to be of
interest are:
txn.drawerid -> drawer.drawerid
txn.batchid -> batch.batchid
I certainly don't mind posting a LOT more info on this. I just didn't
want to spam the list with useless information. If I understood more
about what can cause this kind of error, I could probably find and post
the pertinent info. Can I assume that a plain old select has nothing to
do with this? If so, I can remove the select's from my log and that
will eliminate about 80% of the SQL, making it easier to tell what is
happening.
Thanks, Tom!
--
Matt Mello
