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
|
Список | 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 по дате отправления: