Skip site navigation (1) Skip section navigation (2)

Re: Windows binary downloads/ off the net

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
Cc: pgsql-www <pgsql-www(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Bruce Momjian <bruce(at)momjian(dot)us>, Dave Page <dpage(at)pgadmin(dot)org>
Subject: Re: Windows binary downloads/ off the net
Date: 2010-03-10 09:20:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-www
2010/3/10 Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>:
> On Monday 08 March 2010 10:13:31 Magnus Hagander wrote:
>> 2010/3/8 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> > On Sun, Mar 7, 2010 at 10:31 AM, Stefan Kaltenbrunner
>> >
>> > <stefan(at)kaltenbrunner(dot)cc> wrote:
>> >> Magnus Hagander wrote:
>> >>> 2010/3/7 Bruce Momjian <bruce(at)momjian(dot)us>:
>> >>>> Stefan Kaltenbrunner wrote:
>> >>>>> Hi all!
>> >>>>>
>> >>>>> It seems like that EDB has some serious issues with (non)
>> >>>>> availability of its main domain (looks like somebody forgot to renew
>> >>>>> the domainname and is now waiting for getting the delegation added
>> >>>>> back to the TLD or such).
>> >>>>> This means that it is not impossible for our users to actually
>> >>>>> download the windows binary packages - in the interest of redundancy
>> >>>>> it would probably be a good idea if we at least mirrored those
>> >>>>> packages on our own existing mirror network as well.
>> >>>>> This would allow us to at least offer people an alternative - just in
>> >>>>> case something like this happens again...
>> >>>>
>> >>>> I talked to Jim Mlodgenski of EnterpriseDB and he is working on the
>> >>>> problem with other EDB employees.  :-O
>> >>>
>> >>> I think you are missing the point Stefan is trying to make. We're all
>> >>> sure EDB will fix the problem. But it outlines the fact that the
>> >>> ability for our community to be able to access the official community
>> >>> binaries relies solely on infrastructure the community does not
>> >>> control - in this caes it was the edb domain, it could also be the
>> >>> webservers or whatever.
>> >>>
>> >>> For example, the core RPMs are available both at the pgsqlrpms project
>> >>> *and* through the main mirroring network. We recommend people use the
>> >>> YUM repository on, but they are still available through
>> >>> the main web/ftp system (without the nice automated features and
>> >>> instructions, but the core packages are there) if it goes down.
>> >>
>> >> yeah that is pretty much what I was trying to say - we don't even have
>> >> the official binaries on a community box right now, it seems sensible
>> >> that we should mirror them just as we do with the other stuff so we can
>> >> actually react in case something happens again.
>> >
>> > Except - are these really a community product?  When bug reports are
>> > filed on pgsql-bugs, I thought we fairly routinely referred the poster
>> > to EDB.  Or am I confused?
>> They are a community product, built by EDB.
>> Kind of like the RPMs are a community product, built by either
>> commandprompt or devrim.
> That being the case, there's nothing that would prevent us from just
> downloading a copy each release and sticking them somewhere, right?

AFAIK, nothing, since it only has opensource bits. Other than that we
want to do this in a structured and maintainable way. And I don't mind
having the primary download go just the way it does now, since that's
"the price we pay for having edb doing the packaging for us", so to
speak. But it'd be good to have a backup.

And it'd be even easier if Dave could just  upload it to the ftp
mirror network once he's done putting it on the edb site ;) Dave?

 Magnus Hagander

In response to

pgsql-www by date

Next:From: Ognjen BlagojevicDate: 2010-03-12 09:54:27
Subject: [offtopic] Problems subscribing to Postgres mailing lists
Previous:From: Robert TreatDate: 2010-03-10 02:28:40
Subject: Re: Windows binary downloads/ off the net

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group