Re: %d in log_line_prefix doesn't work for bg/autovacuum workers
От | Christoph Berg |
---|---|
Тема | Re: %d in log_line_prefix doesn't work for bg/autovacuum workers |
Дата | |
Msg-id | 20140517211616.GC9148@msgid.df7cb.de обсуждение исходный текст |
Ответ на | Re: %d in log_line_prefix doesn't work for bg/autovacuum workers (Andres Freund <andres@2ndquadrant.com>) |
Список | pgsql-hackers |
Re: Andres Freund 2014-05-17 <20140517203404.GB4484@awork2.anarazel.de> > > For example, if we allow > > renaming active databases then the subprocesses in a parallel pg_dump or > > pg_restore could connect to the wrong database, ie not the one the leader > > process is connected to. The very best-case outcome of that is confusing > > error messages, and worst-case could be pretty nasty (perhaps even > > security issues?). > > Yea, I am pretty sure there's some nastyness that way. Don't really want > to go there for a feature that's not even been requested. Does pg_dumpall protect against connecting to the wrong database if renames are on the way? To me, this sounds like the same problem as with pg_dump -j. > > We could no doubt teach pg_dump and pg_restore to > > cross-check database OIDs after reconnecting, but lots of other > > applications could have comparable problems. > > I guess pg_dump would have to lock the database before dumping.... Sounds like a sane idea for both. Christoph -- cb@df7cb.de | http://www.df7cb.de/
В списке pgsql-hackers по дате отправления: