Re: dropping partitioned table waits forever

From: "Sriram Dandapani" <sdandapani(at)counterpane(dot)com>
To: "Gregory Stark" <gsstark(at)mit(dot)edu>, "PostgreSQL Admin Discussion" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: dropping partitioned table waits forever
Date: 2006-08-15 21:04:39
Message-ID: 6992E470F12A444BB787B5C937B9D4DF0574F861@ca-mail1.cis.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Thanks for the input. My drop statement is in a loop . I have added a
lock table with nowait before the drop table. At some point(over a
couple of hours, I should be able to get the lock). Not sure why I
don't. All queries that access the parent table finish within 30
minutes(and hence should free up the query plan that accesses the
unwanted child table to be dropped).

The other activity that goes on is a 24x7 insert into the parent table
which has rules that redirect data to appropriate child tables. Not sure
if this requires a shared lock on child tables that do not satisfy the
partition criteria

-----Original Message-----
From: pgsql-admin-owner(at)postgresql(dot)org
[mailto:pgsql-admin-owner(at)postgresql(dot)org] On Behalf Of Gregory Stark
Sent: Tuesday, August 15, 2006 10:27 AM
To: PostgreSQL Admin Discussion
Subject: [ADMIN] dropping partitioned table waits forever

Hm, in my experiments what's happening is that dropping a table needs an
AccessExclusiveLock on the table and any open transactions that have
read from
that table will have at least an AccessShareLock on that table which
blocks
the schema change.

But I don't think merely having a trigger will hold a lock. Will it?
Anyone?

I think you need an actual open transaction that has accessed the table.
Is it
possible you have some transactions that are live for an extended
period?
Either large queries that are still running or just some non-autocommit
transaction sitting waiting for user input before committing?

You could investigate by doing

select * from pg_lock where not granted;

Pick out the one looking for an AccessExclusiveLock, its pid should
match the
pid of the backend where you're doing the DROP. Look at the relation
column
and do

select * from pg_lock where relation = NNN

where NNN is the relation of the nongranted lock.

Look at what type of lock is being held by that's blocking the partition
drop
and what the pid of those backends are. You can see what command they're
executing by using a tool like pg_admin to look at the stats command
buffer or
just by looking at ps usually.

8.2 will allow you to move a partition out of an inheritance structure
instead
of dropping it entirely. Sadly it takes the same lock so it won't help
you
here.

I wonder if it really needs such a strong lock. If it dropped the
inheritance
structure without locking it would open up some strange cases though.
Like,
you wouldn't know just because you had committed that other queries
weren't
still running that think your table is still a partition in the
partitioned
table.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Browse pgsql-admin by date

  From Date Subject
Next Message Jim C. Nasby 2006-08-15 21:27:49 Re: Migration tool
Previous Message Devrim GUNDUZ 2006-08-15 19:03:12 Re: Installing Postgres 8.1.4 on Linux RedHat