Re: ALTER DATABASE RENAME with HS/SR

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: 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 20:55:46
Message-ID: AANLkTik4kEPLw0BotwCnjV0HZrs-R1HGsxrdX+kDkJvA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 4, 2010 at 3:16 PM, Josh Berkus <josh(at)agliodbs(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-10-04 21:32:27 Re: standby registration (was: is sync rep stalled?)
Previous Message Leonardo Francalanci 2010-10-04 20:47:30 Re: I: About "Our CLUSTER implementation is pessimal" patch