> 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@legendplc.com
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.
