Re: Rename a database that has connections

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

In response to

Responses

Browse pgsql-hackers by date

  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