I looked at the thread dump in more detail, and the situation is now less clear.
(1) I see no obvious ManifoldCF-mediated deadlock at all. Everything looks as it should. (2) There are a lot of threads waiting for one particular thread to finish. (3) That thread is waiting to complete a query that *should* complete, according to everything else in ManifoldCF that I can see. If it doesn't complete it should detect database deadlock, in any case. The possibility I am worried about now is that postgresql processes are dying due to some issue, like memory consumption. We therefore need to correlate postgresql processes with threads, so if you can get a ps -elf | grep postgres from the postgres machine and also include that, it would be great. Karl On Mon, Feb 11, 2013 at 11:14 AM, Karl Wright <[email protected]> wrote: > I've confirmed that there's a deadlock of some kind; it's occurring as > a result of the hopcount depth tracking. The issue seems to be nested > transactions; PostgreSQL doesn't appear to be dealing with these > properly in all cases, and winds up getting a deadlock that it doesn't > detect. > > I have to look carefully at the code to see if it can be restructured. > > Karl > > On Mon, Feb 11, 2013 at 10:56 AM, Karl Wright <[email protected]> wrote: >> That is not the reason for the stop. I suspect a deadlock. Trying to >> verify that now. >> >> Karl >> >> >> On Mon, Feb 11, 2013 at 10:44 AM, Erlend Garåsen >> <[email protected]> wrote: >>> On 11.02.13 16.26, Karl Wright wrote: >>>> >>>> trunk has a different schema than 1.1.1. So yes, you'd have to blow >>>> away the old database to go back. >>> >>> >>> OK, who knows. Maybe this was the reason why it just stopped. I'll clean up >>> by deleting all tables and related db resources and try again. >>> >>> Erlend >>> >>> >>> -- >>> Erlend Garåsen >>> Center for Information Technology Services >>> University of Oslo >>> P.O. Box 1086 Blindern, N-0317 OSLO, Norway >>> Ph: (+47) 22840193, Fax: (+47) 22852970, Mobile: (+47) 91380968, VIP: 31050
