> 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? glibc-2.3.2 python-2.2.2 postgresql-python-7.4.10 Linux 2.4.20 > 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. Which indeed appears to have stopped this from being a problem. Thank you very much for all the help. If you'd like any more information (e.g. on versions of things) I may not be around until the new year, but I'll happily provide them once I'm back. Thanks again, Jon -- Best Regards Jonathan Parkin Developer Legend Communications plc T: 0844 390 2049 F: 0844 390 2001 E: jonathan.parkin@xxxxxxxxxxxxx W: http://www.legend.co.uk/ The information in this message is confidential and may be legally privileged. Unauthorised disclosure, copying or distribution, either whole or in part; or action taken in reliance on its content is prohibited. If you are not the intended recipient, please notify Legend Communications immediately.
