Re: autovacuum ignore tables

I tried your code with the lock table followed by drop.

The lock table goes into a wait state AND all INSERTS (even new ones
coming in) go into a wait state.

Ps -ef | grep waiting shows the function call (that does the lock and
drop) in wait state as well as all INSERTS.

All jdbc inserts are committed cleanly. When the commit is done..the
autocommit for the connection is set to true (to flush out any open
transactions)

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Friday, September 29, 2006 7:45 AM
To: Sriram Dandapani
Cc: Matthew T. O'Connor; pgsql-admin(at)postgresql(dot)org
Subject: Re: [ADMIN] autovacuum ignore tables

"Sriram Dandapani" <sdandapani(at)counterpane(dot)com> writes:
> The only issue I have with autovacuum is the fact that I have to
briefly
> stop/restart postgres every couple of days, which kills autovacuum and
> it has no memory of previous work done.

As already stated, this isn't true as of 8.1.

> I work with several databases
> with partitioned tables having high daily volume. Dropping partitioned
> tables locks out jdbc inserts and the drop command itself goes into a
> WAIT state. Hence, I have to stop postgres,update pg_hba.conf to
prevent
> access,restart postgres,drop tables and update pg_hba to allow
> access(Crazy, but I have no choice because Postgres deadlocks on drop
> child tables while inserts happen on the parent)

It sounds to me like you have a problem with failing to commit
transactions promptly. The DROP will wait for existing transactions to
release their locks on the doomed table, but its lock request will block
any incoming transactions that try to acquire new locks on the table.
So basically you should see a hiccup of length equal to the longest
normal transaction using that table. In a well-designed concurrent
system that should not be a problem.

It might be worth doing the DROP as

begin;
lock table parent_table;
drop table child_table;
commit;

so that SELECTs on the parent do simply block and don't risk getting
errors from trying to access a just-dropped child table.

regards, tom lane