Steve Linabery <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
