Re: Rename a database that has connections
От | Mark Kirkwood |
---|---|
Тема | Re: Rename a database that has connections |
Дата | |
Msg-id | 4ECB1ED5.3050108@catalyst.net.nz обсуждение исходный текст |
Ответ на | Re: Rename a database that has connections (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Rename a database that has connections
|
Список | pgsql-hackers |
On 22/11/11 16:38, Bruce Momjian wrote: > 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? > Copying a database is quite a different matter (compare with copying an open unix file vs mv'ing it... the latter is quite safe as the inode does not change). regards Mark
В списке pgsql-hackers по дате отправления: