On Mon, Oct 4, 2010 at 2:42 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> I understand that we need to disconnect users if the database is
>> dropped (it's kind of hard to access a database that's not there any
>> more...) but I'm fuzzy on why we'd need to do that if it is merely
>> renamed.
>
> I think that modern backends might survive that okay (though they didn't
> use to; we once had global variable(s) containing the DB name). But
> it's much less clear that clients would cope sanely. "I'm connected to
> database foo". "No you're not". Connection poolers in particular are
> likely to get bent out of shape by this.
True. Don't we already have some mechanism for notifying clients of
parameter changes they might care about? Could it be adapted to this
situation?
> OTOH, we don't have a similar interlock to prevent renaming users
> who have active sessions, so maybe we are being overprotective here.
I think probably so. I continue to think that we need to work on
reducing the number of things that require interrupting normal
database operation, and anything that requires kicking all users out
of a database falls into that category.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company