Re: [HACKERS] PG_UPGRADE status?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] PG_UPGRADE status?
Дата
Msg-id 1222.936826412@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] PG_UPGRADE status?  (Lamar Owen <lamar.owen@wgcr.org>)
Список pgsql-hackers
Lamar Owen <lamar.owen@wgcr.org> writes:
> [ messiness required to upgrade versions by piping data from a
> pg_dumpall to a psql talking to the new version ]

It'd be considerably less messy, and safer, if you were willing to
stick the pg_dump output into a file rather than piping it on the fly.
Then (a) you wouldn't need to run both versions concurrently, and
(b) you'd have a dump backup if something went wrong during the install.

If you compressed the dump file, which is easy enough, it'd probably
also take less disk space than doing it the other way.  A compressed
dump should usually be a good deal smaller than the database equivalent;
if you do an on-the-fly transfer then the peak usage is two full
on-disk copies of the database...

> You can see how pg_upgrade would be useful in such a scenario, no?

pg_upgrade is hardly a magic panacea --- if the on-disk formats are
at all different, then you really have little choice short of a dump
under the old version and reload under the new.  At most pg_upgrade
might help automate that process a little more.

We may have lost the option of pg_upgrade-like upgrades anyway.
I'm still waiting to hear Vadim's opinion about whether pg_upgrade
can be made safe under MVCC.
        regards, tom lane


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

Предыдущее
От: Edwin Ramirez
Дата:
Сообщение: Re: [HACKERS] Postgres Performance
Следующее
От: Michael Simms
Дата:
Сообщение: Re: [HACKERS] Postgres Performance