On Mon, Oct 4, 2010 at 2:05 AM, Bernd Helmle <maili...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
