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

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: pg_upgrade failing from 9.3 to 9.4 because "template0" already exists
Дата
Msg-id 20150306213557.GY29780@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: pg_upgrade failing from 9.3 to 9.4 because "template0" already exists  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg_upgrade failing from 9.3 to 9.4 because "template0" already exists
Список pgsql-general
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Matt Landry (lelnet.matt@gmail.com) wrote:
> >> postgres=# select datname, datallowconn from pg_database ;
> >> datname  | datallowconn
> >> -----------+--------------
> >> template1 | t
> >> template0 | t
> >> postgres  | t
> >> reporting | t
> >> (4 rows)
>
> > Right, as I mentioned, template0 shouldn't have datallowconn as 'true'.
> > That's why it's being included in the pg_dumpall.
>
> 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 feel no compulsion whatsoever to preserve any user-initiated changes
> in template0 across an upgrade.

I agree with this, with regard to template0.

    Thanks,

        Stephen

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: 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