Re: Tom Lane 2014-05-17 <22961.1400343831@sss.pgh.pa.us>
> I think the key issue comes down to this comment in RenameDatabase:
>
> * XXX Client applications probably store the current database somewhere,
> * so renaming it could cause confusion. On the other hand, there may not
> * be an actual problem besides a little confusion, so think about this
> * and decide.
>
> If we're willing to decide that we will never support renaming an active
> database, then the approach you're proposing makes sense. And it seems
> to me that this issue of potentially confusing client apps is much the
> strongest argument for making such a decision. But is it strong enough?
>
> Given that there haven't been complaints in the past ten years about how
> you can't rename an active database, I'm OK personally with locking this
> down forever. But I wonder if anyone wants to argue the contrary.
Fwiw, we ran into exactly this question yesterday during a customer
training session. Their plan is to provide a database with updated
content every few hours, so their idea was to populate db_new, rename
db to db_old, rename db_new to db, and eventually drop db_old from
cron. This fails when sessions are connected to db. Surprisingly, it
actually works if you do the db renaming on a master server, but let
the (anyway readonly) client connect to a streaming slave. (On 9.2,
didn't test 9.4.)
We also looked into the confused-client problem, but
current_database() reports the new name correctly, and hence figured
there shouldn't be any problem with this approach, despite it
obviously being slightly out of spec because of the dependency on
running on a SR slave. I even jokingly noted that this will probably
get fixed in one or the other direction once I mention it on the
mailing list ;)
So here's your complaint/request that renaming active databases should
be possible...
Christoph
--
cb@df7cb.de | http://www.df7cb.de/
