Skip site navigation (1) Skip section navigation (2)

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 04:05:38
Message-ID: 201111220405.pAM45cx04060@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2011-11-22 04:14:33
Subject: Re: strange nbtree corruption report
Previous:From: Mark KirkwoodDate: 2011-11-22 04:02:29
Subject: Re: Rename a database that has connections

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group