Mark Kirkwood wrote: > 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).
Oh, I see, you are just renaming. Well, Tom is right that either it is safe, or it isn't --- a 'force' flag makes no sense. -- 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
