Re: Tom Lane 2014-05-17 <22961.1400343...@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 -- c...@df7cb.de | http://www.df7cb.de/ -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers