Re: ALTER DATABASE RENAME with HS/SR - Mailing list pgsql-hackers

From Robert Haas
Subject Re: ALTER DATABASE RENAME with HS/SR
Date
Msg-id AANLkTik4kEPLw0BotwCnjV0HZrs-R1HGsxrdX+kDkJvA@mail.gmail.com
Whole thread Raw
In response to Re: ALTER DATABASE RENAME with HS/SR  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On Mon, Oct 4, 2010 at 3:16 PM, Josh Berkus <josh@agliodbs.com> wrote:
> On 10/4/10 10:24 AM, Robert Haas wrote:
>> 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.
>
> This seems like an unexpected benefit, and the behavior which users
> would desire if they could choose it.  Why would we break what's not broken?
>
> +1 to keep ALTER DATABASE functionality the way it is, and merely fix
> the docs.

Well, the current behavior isn't too consistent.  If you try to rename
a database then:

(1) If there's a connection to that database on the primary, it blocks
for a bit and then gives up, complaining of clients connected to that
database.
-but-
(2) If there's a connection to that database on the secondary, it
obviously doesn't block and recovery isn't blocked either.  It just
replays the record and, boom, you're connected to the new database,
except you don't know it.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


pgsql-hackers by date:

Previous
From: Leonardo Francalanci
Date:
Subject: Re: I: About "Our CLUSTER implementation is pessimal" patch
Next
From: Robert Haas
Date:
Subject: Re: standby registration (was: is sync rep stalled?)