On Mon, Oct 4, 2010 at 7:38 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > 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?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers