Re: "deadlock detected" documentation

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