Steve Linabery <slinabery@xxxxxxxxxxxxxxxx> writes: > I just replicated the problem, see below for explanation, but here is ps output: > postgres 25817 3201 55 10:20 ? 00:02:54 postgres: postgres db_being_dumped [local] COPY > postgres 27956 3201 46 10:24 ? 00:00:36 postgres: postgres db_being_dumped [local] COPY > postgres 28124 3201 0 10:25 ? 00:00:00 postgres: dbusername template1 obfus.ip.address.36(49528) DROP DATABASE waiting > postgres 28180 3201 0 10:25 ? 00:00:00 postgres: dbusername db_being_dumped obfus.ip.address.37(48997) startup waiting > postgres 28183 3201 0 10:25 ? 00:00:00 postgres: dbusername db_being_dumped obfus.ip.address.36(49532) startup waiting Hm. DROP DATABASE takes ExclusiveLock on pg_database, which blocks new incoming connections, and both of those things are intentional (part of the point of the lock is to block new connections to the victim database, so it's hard to see how we could avoid this). What doesn't seem so essential though is for pg_dump to be holding a conflicting lock on pg_database. In fact, a plain AccessShareLock wouldn't block DROP DATABASE, so I'm not entirely sure that pg_dump is at fault. Could we see the contents of pg_locks for this situation? regards, tom lane
