On Mon, Oct 4, 2010 at 7:38 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Mon, Oct 4, 2010 at 2:05 AM, Bernd Helmle <mailings@oopsware.de> wrote:
>> Our documentation in
>> <http://www.postgresql.org/docs/9.0/interactive/hot-standby.html> currently
>> says the following:
>>
>> <snip>
>> Running DROP DATABASE, ALTER DATABASE ... SET TABLESPACE, or ALTER DATABASE
>> ... RENAME on the primary will generate a WAL entry that will cause all
>> users connected to that database on the standby to be forcibly disconnected.
>> This action occurs immediately, whatever the setting of
>> max_standby_streaming_delay.
>> </snip>
>>
>> However, renaming a database doesn't trigger a disconnect here on a HS/SR
>> setup:
>>
>> * first, on the primary do:
>>
>> CREATE DATABASE foo;
>>
>> * ...wait until database creation arrived on the standby and connect:
>>
>> psql foo
>>
>> * now rename the database on the primary
>>
>> ALTER DATABASE foo RENAME TO bar;
>>
>> * on the standby do in the same connection as before:
>>
>> foo=# SELECT datname FROM pg_database;
>> datname
>> -----------
>> template1
>> template0
>> postgres
>> bernd
>> pgbench
>> bar
>> (6 rows)
>>
>> That looks contrary to the documented behavior. Shouldn't i get a forced
>> disconnect on this connection instead?
>
> Probably yes. To do that, ISTM that we should make ALTER DATABASE .. RENAME
> issue something like XLOG_DBASE_RENAME record, and make the standby server
> call ResolveRecoveryConflictWithDatabase() when that record is applied.
> Simon?
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company