Re: vacuum deadlock

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Ibrahim Harrani" <ibrahim(dot)harrani(at)gmail(dot)com>, "Yeb Havinga" <yebhavinga(at)gmail(dot)com>
Cc: <pgsql-admin(at)postgresql(dot)org>
Subject: Re: vacuum deadlock
Date: 2010-02-05 18:47:30
Message-ID: 4B6C1362020000250002F02E@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Ibrahim Harrani <ibrahim(dot)harrani(at)gmail(dot)com> wrote:
> Yeb Havinga <yebhavinga(at)gmail(dot)com> wrote:
>> Ibrahim Harrani wrote:

>>> I am using PostgreSQL 8.3.7.
>>> autovacuum is enabled in postgresql.conf
>>>
>>> I got a deadlock while vacuuming all databases with vacuumdb
>>> command.
>>>
>>> vacuumdb: vacuuming of database "mydb" failed: ERROR: deadlock
>>> detected
>>> DETAIL: Process 1294 waits for AccessExclusiveLock on relation
>>> 2662 of database ; blocked by process 1807.
>>> Process 1807 waits for AccessShareLock on relation 1259 of
>>> database 16389; blocked by process 1294.
>>>
>>> I think, because of this lock, deleting a large table (15
>>> million records) was taking too much time
>>> How can I know the name of the relations 2662 and 1259?
>>>
>> postgres=# select oid,relname from pg_class where oid in
>> (2662,1259);
>> oid | relname ------+--------------------
>> 2662 | pg_class_oid_index
>> 1259 | pg_class
>> (2 rows)

> As far as I know, pg_class_oid_index and pg_class are postgresql
> internal relations.
>
> Normally, there is not application that directly using those
> relations.
> How should I map this lock issue on this relations to my
> application side?
> On which cases those are locked and used by applications?

Are you creating temporary tables somehow during this process, like
within functions (including trigger functions)?

Can you test the delete with autovacuum disabled?

When you say "deleting a large table" do you mean, dropping the
table, deleting all rows from the table, or deleting some of the
rows from the table?

If you could show the actual delete statement and all information
about the table(s) involved, including indexes, triggers, and
foreign keys, that might help.

-Kevin

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Josh Kupershmidt 2010-02-05 22:55:33 [patch] pg_cancel_backend for unprivileged users
Previous Message Ibrahim Harrani 2010-02-05 18:14:17 Re: vacuum deadlock