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