On 22/11/11 16:41, Tom Lane wrote:
Mark Kirkwood<mark.kirkw...@catalyst.net.nz> writes:
I've been helping out several customers recently who all seem to be
wrestling with the same issue: wanting to update/refresh non-production
databases from the latest corresponding prod version. Typically they
have (fairly complex) scripts that at some point attempt to restore a
dump into new database and then rename the to-be-retired db out of the
way and rename the newly restored one to take over.
In many cases such scripts would be simplified if a database could be
renamed without requiring its connections terminated. I've been asked
several times if this could be added... so I've caved in a done a patch
that allows this.
The default behavior is unchanged - it is required to specify an
additional trailing FORCE keyword to elicit the more brutal behavior.
Note that existing connections to the renamed database are unaffected,
but obviously SELECT current_database() returns the new name (in the
next transaction).
This patch seems to me to be pretty thoroughly misguided. Either
renaming a database with open connections is safe, or it isn't. If it
is safe, we should just allow it. If it isn't, making people write an
extra FORCE keyword does not make it safe. It's particularly silly
to allow someone to rename the database out from under other sessions
(which won't know what happened) but not rename it out from under his
own session (which would or at least could know it).
What you need to be doing is investigating whether the comments about
this in RenameDatabase() are really valid concerns or not.
The reason I added FORCE was to preserve backwards compatibility - for
any people out there that like the way it behaves right now. I am
certainly willing to be convinced that such a concern is unneeded.
You are quite right about the patch being inconsistent with respect to
the renaming the current database, it should allow that too (will change
if this overall approach makes sense).
With respect to the concerns in RenameDatabase(), that seems to boil
down to applications stashing the current dbname somewhere and caring
about it. This was not viewed as a issue by any of the folks who I
talked to about this (they are all application developers/architects etc
so they understand that issue). However there may well be application
frameworks out there that do care... which seemed to me to be another
reason for making the forced rename require an extra keyword.
I have not been able to find any other problems caused by this...
renaming a db (many times) with hundreds of pgbench connections does not
give rise to any issues.
regards
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
