Re: new --maintenance-db options

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: new --maintenance-db options
Дата
Msg-id CA+Tgmob0A9qvWSp38HNzC78b5wjXfH9mpee2Y=gL9WcOVfQdwQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: new --maintenance-db options  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: new --maintenance-db options  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: new --maintenance-db options  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: new --maintenance-db options  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Mon, Jun 25, 2012 at 2:49 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Excerpts from Robert Haas's message of lun jun 25 11:57:36 -0400 2012:
>> Really, I think
>> pg_upgrade needs this option too, unless we're going to kill the
>> problem at its root by providing a reliable way to enumerate database
>> names without first knowing the name one that you can connect to.
>
> I think pg_upgrade could do this one task by using a standalone backend
> instead of a full-blown postmaster.  It should be easy enough ...

Maybe, but it seems like baking even more hackery into a tool that's
already got too much hackery.  It's also hard for pg_upgrade to know
things like - whether pg_hba.conf prohibits access to certain
users/databases/etc. or just requires the use of authentication
methods that happen to fail.  From pg_upgrade's perspective, it would
be nice to have a flag that starts the server in some mode where
nobody but pg_upgrade can connect to it and all connections are
automatically allowed, but it's not exactly clear how to implement
"nobody but pg_upgrade can connect to it".

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: Catalog/Metadata consistency during changeset extraction from wal
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: new --maintenance-db options