On Mon, Oct 4, 2010 at 2:42 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
