On 2014-05-17 23:35:43 +0200, Christoph Berg wrote: > They want to pg_terminate_backend() the sessions on db_old anyway, but > to get that point, you need to be able to rename the db. The > alternative would be to disallow connections to the db (for which > there is no real nice way), kill existing connections, do the > renaming, and then reenable connections. That's much more effort, > though.
There should really be a way to set datallowcon... But anyway, you can set the connection limit to 0, that should mostly work? > Fwiw, this wasn't the first time I've heard of that idea, it also > doesn't sound too far-fetched for me. I guess people usually go "damn, > I can't rename active dbs, let's try something else" instead of > complaining on the mailing lists in that case. Hm. > > > 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 guess if you are doing database renames, you can live with that, > especially if you are doing the renames only for the purpose of > putting an updated db in place, and then throwing away the old db > quickly. I don't know. If you switch databases around, for example, and sessions on both report the original database name things really get confusing. 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
