Re: [pgsql-www] Upcoming PG re-releases

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: [pgsql-www] Upcoming PG re-releases
Дата
Msg-id 438F312A.4080602@dunslane.net
обсуждение исходный текст
Ответ на Re: [pgsql-www] Upcoming PG re-releases  ("Dave Page" <dpage@vale-housing.co.uk>)
Список pgsql-hackers

Dave Page wrote:

>
>
>
>
>>-----Original Message-----
>>From: pgsql-www-owner@postgresql.org
>>[mailto:pgsql-www-owner@postgresql.org] On Behalf Of Marc G. Fournier
>>Sent: 01 December 2005 17:01
>>To: Peter Eisentraut
>>Cc: pgsql-hackers@postgresql.org; Euler Taveira de Oliveira;
>>Richard Huxton; Robert Treat; Magnus Hagander; Marc G.
>>Fournier; pgsql-www@postgresql.org; Tom Lane; Andrew Dunstan
>>Subject: Re: [pgsql-www] [HACKERS] Upcoming PG re-releases
>>
>>On Thu, 1 Dec 2005, Peter Eisentraut wrote:
>>
>>
>>
>>>Am Donnerstag, 1. Dezember 2005 11:35 schrieb Euler Taveira
>>>
>>>
>>de Oliveira:
>>
>>
>>>>What about an museum.postgresql.org to keep the old releases?
>>>>
>>>>
>>>That gave me a good laugh, but there is something to be
>>>
>>>
>>said about moving all
>>
>>
>>>no longer supported releases (according to the criteria
>>>
>>>
>>that are being
>>
>>
>>>discussed) to an unmirrored site, say, archive.postgresql.org.
>>>
>>>
>>That would be fairly trivial ... let me add it to the 'todo
>>list' ... I
>>take it that it would be safe to relegate the /pub/source/OLD
>>stuff there
>>too?
>>
>>
>
>Not so trivial to put behind a web interface or the download tracker
>though. Is it really necessary to have a separate archive downloads
>site? It's not like the old ones get in the way, or cost anything other
>than disk space on the mirrors to store (and I've only ever heard mirror
>admins say how small our site is compared to many others!).
>
>Plus of course, weren't we trying to reduce the number of VMs/sites?
>
>
>
>

Agreed. I see no virtue in this at all. If we continue to make stuff
available it must be because someone will need it. I can see that
happening if some catastrophe happens on an old system, in which case
the person hunting is likely to need to find it easily and possibly fast.

The network traffic involved in mirroring something that doesn't change
is usually trivial, and disk space seems to be at most a few $ per Gb
these days, so surely this is not a resource issue.

cheers

andrew

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

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: [ADMIN] ERROR: could not read block
Следующее
От: "Qingqing Zhou"
Дата:
Сообщение: Re: generalizing the planner knobs