Re: PostgreSQL 7.4.10 hanging on delete

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jonathan Parkin <jonathan(dot)parkin(at)legendplc(dot)com>
Cc: PostgreSQL Admin Mailing List <pgsql-admin(at)postgresql(dot)org>
Subject: Re: PostgreSQL 7.4.10 hanging on delete
Date: 2005-12-21 15:19:05
Message-ID: 13239.1135178345@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Jonathan Parkin <jonathan(dot)parkin(at)legendplc(dot)com> 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

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2005-12-21 16:13:45 Re: Changing locale
Previous Message KJ 2005-12-21 10:50:12 Query Tool new/change connection