Re: Upgrading rant.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Upgrading rant.
Дата
Msg-id 5302.1041733300@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Upgrading rant.  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> This would require a nontrivial amount of work (notably, we'd have to
>> be able to get pg_dump to run against a standalone backend) but I don't
>> think I'd trust pg_upgrade as a production-grade tool until its
>> invocation method looks like the above.

> I would recommend requiring users to do the schema dump before upgrading
> the binaries, so they'd do

Hm.  I think we'd need to have the new version's pg_upgrade (we cannot
be sure that an older version would be aware of what information must be
dumped), and the newer pg_dump is also likely to be a better bet than
the old (we've seen several times in the past that this allows us to get
around problems in a prior version of pg_dump).  But we'd need access to
the old version's postmaster/postgres executable, since by assumption
the newer one will not run in the old data directory.

I recall Lamar complaining often about the need for multiple executable
versions to be available simultaneously.  Can we perhaps alter the
packaging to make this easier?  I'm envisioning for example installing
the postmaster/postgres executable as "postgres.7.5", with symlinks from
"postmaster" and "postgres"; then we need not overwrite "postgres.7.4"
and that could be invoked by pg_upgrade.  (I'm just brainstorming here,
this isn't necessarily a serious proposal.  Better ideas anyone?)
        regards, tom lane


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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Upgrading rant.
Следующее
От: Justin Clift
Дата:
Сообщение: Re: New Portal in Place, DNS switched ...