Re: pg_dump versus ancient server versions

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: pg_dump versus ancient server versions
Дата
Msg-id aa3c0742-a77b-14db-58ef-9b30986cb38c@dunslane.net
обсуждение исходный текст
Ответ на Re: pg_dump versus ancient server versions  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 12/2/21 12:30, Tom Lane wrote:
>
>> In practice, the effort can focus on keeping the most recent cutoff
>> release buildable.  So in the above example, we really only need to
>> keep PG >=9.2 buildable to support ongoing development.  The chances
>> that some needs to touch code pertaining to older versions in
>> backbranches is lower, so those really would need to be dealt with
>> very rarely.
> OK.  Also, when you do need to check that, there are often other ways
> than rebuilding the old branch on modern platforms --- people may
> well have still-executable builds laying about, even if rebuilding
> from source would be problematic.
>
>             



I have a very old fedora instance where I can build every release back
to 7.2 :-) And with only slight massaging for the very old releases,
these builds run on my Fedora 34 development system. Certainly 8.2 and
up wouldn't be a problem. Currently I have only tested building without
any extra libraries/PLs, but I can look at other combinations. So, long
story short this is fairly doable at least in some environments. This
provides a good use case for the work I have been doing on backwards
compatibility of the TAP framework. I need to get back to that now that
the great module namespace adjustment has settled down.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com




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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Commitfest 2021-11 Patch Triage - Part 1
Следующее
От: "Bossart, Nathan"
Дата:
Сообщение: Re: O(n) tasks cause lengthy startups and checkpoints