Jonathan Parkin <jonathan.parkin@xxxxxxxxxxxxx> writes: > On Tue, 2005-12-20 at 16:37, Tom Lane wrote: >> If this is a specific row causing the issue, then I'd wonder about >> data corruption of some sort. It might be worth looking at the >> table with pg_filedump (from http://sources.redhat.com/rhdb/). > Our current plan is to do a rebuild of the database tonight (UK time). > This would hopefully eliminate any such data corruption. Given the stack traces, I no longer think it's a data corruption issue --- somehow libc is screwing up. Backends are single-threaded and there is *no* reason for pthread_mutex_lock to block, ever. I have a vague recollection that we saw something similar reported once before, but it was awhile ago [ digs... ] Here it is: http://archives.postgresql.org/pgsql-admin/2003-07/msg00303.php and later http://archives.postgresql.org/pgsql-admin/2003-08/msg00064.php We never did figure out what was up, but it is striking that the other reporter was also using plpython. It begins to look like Python is somehow contributing to the problem. What versions of python and glibc are you running, exactly? If you just want to get your production machine back to stability, I'd recommend the workaround suggested in that thread, which is to not use syslog-based logging. regards, tom lane