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

Re: Rename a database that has connections

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(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:41:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> writes:
> 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).

This patch seems to me to be pretty thoroughly misguided.  Either
renaming a database with open connections is safe, or it isn't.  If it
is safe, we should just allow it.  If it isn't, making people write an
extra FORCE keyword does not make it safe.  It's particularly silly
to allow someone to rename the database out from under other sessions
(which won't know what happened) but not rename it out from under his
own session (which would or at least could know it).

What you need to be doing is investigating whether the comments about
this in RenameDatabase() are really valid concerns or not.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2011-11-22 03:43:23
Subject: Re: strange nbtree corruption report
Previous:From: Bruce MomjianDate: 2011-11-22 03:38:35
Subject: Re: Rename a database that has connections

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