Re: Hardening pg_upgrade

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Hardening pg_upgrade
Дата
Msg-id 17585.1408993492@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Hardening pg_upgrade  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Hardening pg_upgrade  (Bruce Momjian <bruce@momjian.us>)
Re: Hardening pg_upgrade  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> OK, I will move in the direction of removing 8.3 support and use a
> single query to pull schema information.   I was hesistant to remove 8.3
> support as I know we have kept pg_dump support all the way back to 7.0,
> but it seems pg_upgrade need not have the same version requirements.

Not really related, but ... I've been thinking that it's time to rip out
pg_dump's support for server versions before 7.3 or 7.4.  That would let
us get rid of a lot of klugy code associated with the lack of schemas
and dependency info in the older versions.  It's possible that we should
move the cutoff even further --- I've not looked closely at how much could
be removed by dropping versions later than 7.3.

Aside from the question of how much old code could be removed, there's the
salient point of how do we test pg_dump against such old branches?  The
further back you go the harder it is to even build PG on modern platforms,
and the less likely it will work (I note for example that pre-8.0
configure doesn't try to use -fwrapv, let alone some of the other switches
we've found necessary on recent gcc).  I've usually tested pg_dump patches
against old servers by running them against builds I have in captivity on
my old HPPA box ... but once that dies, I'm *not* looking forward to
trying to rebuild 7.x on my current machines.
        regards, tom lane



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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Verbose output of pg_dump not show schema name
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Set new system identifier using pg_resetxlog