Re: pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_upgrade failing from 9.3 to 9.4 because "template0" already exists
Дата
Msg-id 7389.1425679049@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_upgrade failing from 9.3 to 9.4 because "template0" already exists  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: pg_upgrade failing from 9.3 to 9.4 because "template0" already exists  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-general
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Perhaps pg_upgrade should deliberately ignore template0 regardless of
>> datallowconn?  And/or we should hard-wire that into pg_dumpall?

> My thinking would be that pg_dumpall should be hard-wired for template0
> (just like it is for template1..) and that we should *not* be excluding
> databases that are marked as datallowconn = false..  That said, it's not
> clear to me what to do there instead.  Maybe throw an error or a
> warning?  The point of pg_dumpall is to dump *all* the databases and at
> least the manpage doesn't appear to say anything about "but ignores
> databases with datallowconn = false".

I think pg_upgrade and pg_dumpall may be two different use-cases.
pg_upgrade should definitely throw a hard error if there are any
non-template0 databases that it can't connect to, because the alternative
is losing such databases during the upgrade.  I'm not sure that the
argument is so black-and-white for pg_dumpall, though.  Nobody's ever
complained about it skipping unconnectable databases, and that behavior
has been there since we invented datallowconn (cf commit 2cf48ca04bf599).

            regards, tom lane


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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: pg_upgrade failing from 9.3 to 9.4 because "template0" already exists
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: How to get plpython2 in /lib?