Mark Kirkwood wrote: > 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).
Uh, it isn't save to copy a database when someone else is connected. How does this address that issue? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
