From: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Rename a database that has connections |
Date: | 2011-11-22 04:02:29 |
Message-ID: | 4ECB1ED5.3050108@catalyst.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2011-11-22 04:05:38 | Re: Rename a database that has connections |
Previous Message | Tom Lane | 2011-11-22 03:43:23 | Re: strange nbtree corruption report |