Re: 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