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

RPMs for 7.3.4, and a change.

From: Lamar Owen <lowen(at)pari(dot)edu>
To: pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org,pgsql-ports(at)postgresql(dot)org
Subject: RPMs for 7.3.4, and a change.
Date: 2003-07-28 22:55:20
Message-ID: 200307281855.20976.lowen@pari.edu (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackerspgsql-ports
Good evening.

RPMs for PostgreSQL 7.3.4, built on three architectures, are in the midst of 
uploading to ftp.postgresql.org, in /pub/binary/v7.3.4/RPMS.  As usual, 
inside that directory is the directory SRPMS, which contains the source RPM, 
as well as the three binary RPM directories I am uploading.  One minor thing; 
a source RPM suitable for rebuilding on Red Hat 7.3 is available in the 
aurora-1.0 subdirectory.  Aurora 1.0 is basically Red Hat 7.3 for SPARC; 
there are also SPARC binaries there.

Other than the version change, this RPMset includes the correct JDBC jars.  
There are a couple of fixes that have been e-mailed to me that are not in 
this update; I will address those as soon as I can.

In other news, I have changed jobs.  Previously, I worked full-time as a 
broadcast engineer/IT person for WGCR Radio.  I still work part-time for 
them, amongst other radio stations, but my full-time position is now as 
Director of Information Technology for Pisgah Astronomical Research Institute 
(PARI), a radio/optical astronomical observatory located in Western North 
Carolina.  You can find out more about PARI at our website, www.pari.edu.

PARI is already using PostgreSQL for several applications, and soon will be 
looking at PostgreSQL for a large data warehousing application.  And, in this 
case, I do mean large.  I will be indexing and storing over three million 
astronomical photographic plates (if plans come together!), where each plate 
will scan in at roughly 650-750MB in size (uncompressed) (and this is 8-level 
grayscale scanning).  Mass storage will be critical of this priceless data 
store, and PostgreSQL may very well fit the bill.  I'm still in the planning 
phases, and we are still trying to secure funding for this project.  But I am 
relatively confident that PostgreSQL will rise to the occassion.  Some of the 
plates in question are over 100 years old.

New challenges, new opportunities.  But still the same PostgreSQL.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute

Responses

pgsql-ports by date

Next:From: Ron JohnsonDate: 2003-07-28 23:05:57
Subject: Re: RPMs for 7.3.4, and a change.
Previous:From: Bruce MomjianDate: 2003-07-25 15:55:01
Subject: Re: Update PG-7.3.2 and tru64 5.1a

pgsql-hackers by date

Next:From: Tom LaneDate: 2003-07-28 23:05:25
Subject: Re: Regression test failure date.
Previous:From: Bruce MomjianDate: 2003-07-28 22:35:35
Subject: Re: Regression test failure date.

pgsql-general by date

Next:From: Ron JohnsonDate: 2003-07-28 23:05:57
Subject: Re: RPMs for 7.3.4, and a change.
Previous:From: Jonathan BartlettDate: 2003-07-28 21:47:38
Subject: Re: CREATE TABLE with REFERENCE

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