Re: Rename a database that has connections
От | Bruce Momjian |
---|---|
Тема | Re: Rename a database that has connections |
Дата | |
Msg-id | 201111220338.pAM3cZ200105@momjian.us обсуждение исходный текст |
Ответ на | Rename a database that has connections (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>) |
Ответы |
Re: Rename a database that has connections
|
Список | pgsql-hackers |
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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: