Re: %d in log_line_prefix doesn't work for bg/autovacuum workers

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