Re: ALTER DATABASE RENAME with HS/SR

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Bernd Helmle <mailings(at)oopsware(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: ALTER DATABASE RENAME with HS/SR
Date: 2010-10-04 19:13:31
Message-ID: AANLkTikJ5-TB3Kx_C-vxQedABz6Ak2UzAVbfmA3vM-6e@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 4, 2010 at 2:42 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2010-10-04 19:16:28 Re: ALTER DATABASE RENAME with HS/SR
Previous Message Robert Haas 2010-10-04 19:05:51 Re: Basic JSON support