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@xxxxxxxxxxxxx] Sent: Friday, September 29, 2006 7:45 AM To: Sriram Dandapani Cc: Matthew T. O'Connor; pgsql-admin@xxxxxxxxxxxxxx Subject: Re: [ADMIN] autovacuum ignore tables "Sriram Dandapani" <sdandapani@xxxxxxxxxxxxxxx> 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
