Re: Rename a database that has connections - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Rename a database that has connections
Date
Msg-id 201111220338.pAM3cZ200105@momjian.us
Whole thread Raw
In response to Rename a database that has connections  (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>)
Responses Re: Rename a database that has connections
List 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 by date:

Previous
From: Noah Misch
Date:
Subject: Re: strange nbtree corruption report
Next
From: Tom Lane
Date:
Subject: Re: Rename a database that has connections