On 2014-05-17 23:10:42 +0200, Christoph Berg wrote: > > 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.)
Ick. That's a bug imo. It should cause a recovery conflict disconnecting active sessions with force... I'd very much discourage your users from relying on this. Independent of my complaint about %d this isn't something that's supported and it won't change unless somebody puts non-neglegible resources into it. > 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. At the very least log_line_prefix's %d will log the wrong thing. > I even jokingly noted that this will probably > get fixed in one or the other direction once I mention it on the > mailing list ;) Heh. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
