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?
--
Thanks
Bernd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
