Steve Linabery <slinabery@worldcycling.com> 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
DATABASEwaiting
> postgres 28180 3201 0 10:25 ? 00:00:00 postgres: dbusername db_being_dumped obfus.ip.address.37(48997)
startupwaiting
> postgres 28183 3201 0 10:25 ? 00:00:00 postgres: dbusername db_being_dumped obfus.ip.address.36(49532)
startupwaiting
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
