Re: Waiting for Disconnect

David Wheeler <david(at)kineticode(dot)com> writes:
> I have some tests that create a database, run a bunch of tests against
> it, and then drop it. But I was running into an issue where I'd get
> this error even after I disconnected from the test database:

> ERROR: source database "foo" is being accessed by other users

Yeah, I've seen this too. The problem is that the backend you were
using hasn't exited yet when you try to issue the DROP DATABASE.
This is a bit surprising given the small amount of work normally
needed for a backend to exit. (If it has to drop temp tables or
something, that might be another story, but I've seen it happen
with no such cleanup work needed.)

As best I can tell, it happens because the kernel has simply given
no, none, zero cycles to the orphaned backend, preferring instead
to run your shell, psql, and the postmaster. I suppose this is
because some scheduler heuristic inside the kernel has decided that
the backend is a "background" process that deserves low priority.
I get the impression that some platforms are more prone to this than
others, which is consistent with the idea that it's a scheduler issue.

The only real solution I know of is to sleep for a little before
trying to issue the DROP DATABASE. Certainly, adding more database
traffic as you suggest isn't going to improve matters.

regards, tom lane