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?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center