Martijn, Thanks for the info. The binary is compiled by myself, with mostly the default options as checked out from CVS, so it's stripped as much as the default make options do that... I already checked the pg_locks view, with some results documented in my post about the first time this kind of problem happend: http://archives.postgresql.org/pgsql-general/2005-11/msg00828.php I can say it was not a deadlock, at least not detected by postgres. I've used strace before occasionally, so that one is not a stranger for me, just didn't cross my mind at all and needed to act fairly quickly. Next time I'll use it. Thanks, Csaba. On Fri, 2005-11-18 at 18:58, Martijn van Oosterhout wrote: > On Fri, Nov 18, 2005 at 03:55:01PM +0100, Csaba Nagy wrote: > > Richar, Martijn, > > > > Thanks for answering, but I had to kill the process in the meantime. I > > tried kill -11 in the hope it will produce a core dump at least, but it > > either didn't dump core or I don't know where to look for it as I can't > > find it. > > <snip> > > > So, in order to find out what's going on, what should I do if it happens > > again ? Use gdb, and do what ? > > Strace is a good idea, I'll do that too if there is a next time. > > The most useful thing is to type "bt" to get a backtrace. Unfortunatly, > if you've got a stripped binary the output will be totally unreadable. > But we can hope. > > strace tells you the system calls it's doing. If it's stuck in a loop > in userspace this won't print much useful, but that fact is useful in > itself. Finally there is ltrace which lists library calls. Somewhat > more invasive, but can sometimes produce something where strace > doesn't. > > There are tables for the current locks, but you'll need to look in the > docs for that. > > Have a nice day,
