From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dietmar May <dcmay@dmis.com>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: Race condition with libpq
Date: Mon, 26 May 2003 02:06:58 -0400
Message-ID: <25801.1053929218@sss.pgh.pa.us> (raw)
In-Reply-To: <009c01c31ce9$eeaf00f0$fb02a8c0@muskrat>
References: <009c01c31ce9$eeaf00f0$fb02a8c0@muskrat>
"Dietmar May" <dcmay@dmis.com> writes:
> ... If just executing without any time lag between calls (i.e. no
> human interaction), then I consistently and repeatably receive the error
> "Drop database failed : ERROR: DROP DATABASE: database \"somedb\" is being
> accessed by other users\n".
> The "other user" is the PGconn that was just released using a PGfinish!
Yeah, we have seen this behavior reported before; though I've not found
it to be easily reproducible myself. It's pretty hard to believe that a
backend shutdown would take longer than a backend startup; so my take on
it is that for some reason, the kernel is not choosing to promptly
report closure of the first connection to the first backend. Normally
it doesn't matter much if a backend is slow to exit ... but it does if
you wanna drop its database.
My recommendation would be not to connect to the victim database at all.
Connect to template1, then try to issue a DROP DATABASE. You don't much
care if that fails. Then issue CREATE DATABASE.
A marginally cleaner-sounding approach is to look in pg_database (from
your connection to template1) to see if you need to issue the DROP.
But when you think about race conditions with other people doing the
same procedure, I'm not sure this is really any cleaner.
> I consider it a reasonable expectation to connect to the PGsql server
> without opening any database, and being able to perform some basic
> operations that do not rely on having an open database (CREATE USER, ALTER
> USER, DROP USER, CREATE DATABASE, DROP DATABASE, etc).
There is no such thing as a "connection that doesn't open any database",
and I do not think there could be. The convention is to connect to
template1, which is supposed to be there. We could perhaps put stronger
restrictions on what you could do to template1, to positively ensure
that template1 is always available to connect to --- but that wouldn't
really solve the problem you discuss above.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: tgl@sss.pgh.pa.us, dcmay@dmis.com
Subject: Re: Race condition with libpq
In-Reply-To: <25801.1053929218@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox