Re: a heavy duty operation on an "unused" table kills my server

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Eduardo Piombino <drakorg(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: a heavy duty operation on an "unused" table kills my server
Date: 2010-01-13 18:11:32
Message-ID: dcc563d11001131011w6c06d5aeo153c060633def9c9@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, Jan 13, 2010 at 10:54 AM, Eduardo Piombino <drakorg(at)gmail(dot)com> wrote:
>
>> OK, I'm not entirely sure this table is not still locking something
>> else.  If you make a copy by doing something like:
>>
>> select * into test_table from a;
>>
>> and then alter test_table do you still get the same problems?  If so,
>> then it is an IO issue, most likely.  If not, then there is some
>> client connection still referencing this table or something and that
>> could cause this type of behaviour as well.
>
> I can guarantee you that the table is not being referenced by any other
> thread, table or process, and that it is totally unrelated to everything
> else in the system.

If you rename a table that WAS being referenced by other threads, then
it might still be being accessed or waited on etc by those threads, as
their transaction would have started earlier.

The only way you can guarantee it's not being reference in some way is
to create it fresh and new as I suggested and test on that. Until
then, your guarantee is based on a belief, not verifiable fact. I too
tend to believe this is an IO problem btw, but claiming that it can't
be a problem with some locks without looking at pg_locks at least, is
a bit premature.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Greg Smith 2010-01-13 18:46:03 Re: a heavy duty operation on an "unused" table kills my server
Previous Message Eduardo Piombino 2010-01-13 17:54:36 Re: a heavy duty operation on an "unused" table kills my server