Re: Rename a database that has connections

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Rename a database that has connections
Date: 2011-11-22 03:38:35
Message-ID: 201111220338.pAM3cZ200105@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-11-22 03:41:27 Re: Rename a database that has connections
Previous Message Noah Misch 2011-11-22 03:17:45 Re: strange nbtree corruption report