PostgreSQL 7.2.1-2PGDG RPMs available for RedHat-skipjack 7.2.93 and RedHat 6.2/SPARC
RPMs for 7.2.1 are immediately available for download from
ftp://ftp.postgresql.org/pub/binary/v7.2.1/RPMS
Binary RPMs available are for RedHat-skipjack 7.2.93 and RedHat 6.2/SPARC, and
the source RPM is in SRPMS.
To rebuild on RedHat 7.x, simply rpm --rebuild if you have the necessary
development packages installed. In particular, since tk is a build target,
the development libs for X are required for the full build. See
README.rpm-dist, available in the source RPM, for details on the conditional
build system.
To rebuild on RedHat 6.2, use 'rpm --define "build6x 1" --rebuild' to rebuild.
The build6x option disables SSL, kerberos, and NLS support, as well as tuning
the dependencies for Red Hat 6.2 versus 7.x. If you have gettext, krb5,
and/or OpenSSL installed on your RedHat 6.2 box (those packages are not stock
options in a usable form), visit the postgresql.spec file and edit the top
few lines accordingly. However, since the 6.2 package dependencies are
modifiied by the build6x option, you still need to define it. And don't
define it to 0 for non-6.x builds, as the state of being undefined or defined
is used as a conditional as well.
Please see the changelog included in postgresql.spec in the source RPM for
details on what else has changed.
There are a few patches and fixes I still need to apply from people, but these
RPMs are stable and build on both RHL 7.2.93 (skipjack public beta) and
RedHat 6.2/SPARC (the only RHL 6.2 machine I have available to me). I will
be uploading RPMs built on stock fully updated RHL 7.2 Monday.
Incidentally, the 7.2.93 (skipjack) public beta is a serious improvement over
RHL 7.2, and I personally recommend it, as KDE 3 is worth the upgrade, even
to a beta.
My apologies for the long delay since the 7.2-1 RPM release. Since RedHat 6.2
support seemed important to many people, I took my time making sure I could
actually rebuild on RHL 6.2. This required me to have a 6.2 box at my
disposal to build upon. So I bought a SPARCclassic for $1.25 off ebay,
outfitted it with 64MB RAM and a 4.5GB SCSI HD, and installed RHL 6.2/sparc
on it. And it took a long time to figure out what was broken with the
sparc32 build system on it. But I got it figured out and fixed, and it now
builds. On a SPARCclassic (sun4m, MicroSPARC I @ 50MHZ) the build is very
long (over 1 hour), but you can't beat the price, and the reliability of the
hardware. Plus, it's quite cute.
NOTE: I will only directly support RHL 7.2 and later on Intel, and 6.2 on
SPARC. RHL 7.1 and RHL 7.0 are not directly supported by me as I have no
machines running those versions at my disposal. In addition, I will only
support RedHat 6.2 on SPARC directly -- and my SPARCclassic has _all_ the
errata installed, including the RPM 4.x packages. To use my source RPM's you
will need a version of RPM that understands features available to RPM 4.x.
I do have access to a Caldera/SCO OpenUnix box using Linux emulation thanks to
Larry Rosenman, even though I've not availed myself of that access as yet.
Other none-RedHat RPM-based distributions are not directly supported by me,
although SuSE 7.3 on UltraSparc may be supported in the future, as I have an
Ultra 5 running that dist.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
On Sun, 2002-04-14 at 08:48, Lamar Owen wrote:
Incidentally, the 7.2.93 (skipjack) public beta is a serious improvement over
RHL 7.2, and I personally recommend it, as KDE 3 is worth the upgrade, even
to a beta.
Is the 7.2.93 (skipjack) public beta an improvement in raw postgresql
performance or just in added stuff like KDE ?
----------------------------
Hannu
[Trimmed CC list]
On Sunday 14 April 2002 01:52 am, Hannu Krosing wrote:
On Sun, 2002-04-14 at 08:48, Lamar Owen wrote:
Incidentally, the 7.2.93 (skipjack) public beta is a serious improvement
over RHL 7.2, and I personally recommend it, as KDE 3 is worth the
upgrade, even to a beta.
Is the 7.2.93 (skipjack) public beta an improvement in raw postgresql
performance or just in added stuff like KDE ?
Hmmm.
Raw performance seems to be increased as well, due to an improved kernel
(2.4.18 plus low-latency and preemptible patches, according to the kernel
source RPM). Although I am a little overwhelmed by the increased performance
of this new Athlon 1.2+512MB RAM versus my old Celeron 650+192MB RAM, 7.2.93
seems to be faster on the same hardware.
Particularly during the regression tests.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
On Sun, Apr 14, 2002 at 02:35:13PM -0400, Lamar Owen wrote:
Hmmm.
Raw performance seems to be increased as well, due to an improved kernel
(2.4.18 plus low-latency and preemptible patches, according to the kernel
source RPM).
The low-latency and preemptible patches are not meant for performance
gains, but for responsiveness, and are not designed to be used in servers,
only in workstations/desktops.
Although I am a little overwhelmed by the increased performance
of this new Athlon 1.2+512MB RAM versus my old Celeron 650+192MB RAM, 7.2.93
seems to be faster on the same hardware.
2.4.18 does come with a improved VM, what could justify the performance
increase. As could an update on the compiler (I've being using gcc 3.1 in
my redhat 7.2).
But I can't recomend the beta to anyone, we had problems with one
dual pentium iii server, causing random corruption on
/usr/include/*.h and a lock up.
Regards,
Luciano Rocha
--
Luciano Rocha, strange@nsk.yi.org
The trouble with computers is that they do what you tell them, not what
you want.
-- D. Cohen
On Sunday 14 April 2002 03:00 pm, Luciano Miguel Ferreira Rocha wrote:
On Sun, Apr 14, 2002 at 02:35:13PM -0400, Lamar Owen wrote:
Raw performance seems to be increased as well, due to an improved kernel
(2.4.18 plus low-latency and preemptible patches, according to the kernel
source RPM).
The low-latency and preemptible patches are not meant for performance
gains, but for responsiveness, and are not designed to be used in servers,
only in workstations/desktops.
ISTM that improving interactive performance would also improve multiuser
performance in a server, as low latency and kernel preemption can increase
multiuser server responsiveness.
Although I am a little overwhelmed by the increased performance
of this new Athlon 1.2+512MB RAM versus my old Celeron 650+192MB RAM,
7.2.93 seems to be faster on the same hardware.
2.4.18 does come with a improved VM, what could justify the performance
increase. As could an update on the compiler (I've being using gcc 3.1 in
my redhat 7.2).
The stock gcc on 7.2.93 is still the RedHat-branded 2.96, but with lots of
fixes backported from higher versions.
However, the improved VM may indeed be a large part of it. It sure feels
faster.
But I can't recomend the beta to anyone, we had problems with one
dual pentium iii server, causing random corruption on
/usr/include/*.h and a lock up.
Did you happen to report it to Red Hat's Skipjack list, or to
bugzilla.redhat.com/bugzilla? Helps make a better dist!
I have had less problems thus far with 7.2.93 than I ever did with 7.2.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Lamar Owen wrote:
The low-latency and preemptible patches are not meant for performance
gains, but for responsiveness, and are not designed to be used in servers,
only in workstations/desktops.ISTM that improving interactive performance would also improve multiuser
performance in a server, as low latency and kernel preemption can increase
multiuser server responsiveness.
responsiveness != performance IT works OK for a low number of
concurrent users/processes to increase percieved performance, but to get
real gains on large systems with large numebrs of users and processes
you actually decrease the responsiveness of individual tasks (IE make
the system a little less likely to context switch or pre-empt) and
schedual in batches or clusters rather than one-at-a-time. For a
desktop/workstation this would be insane, and drive a user to kill
someone, but for systems that handle several hundred users (interactive
or not) this improves overall perfomance.
2.4.18 has a lot of work done to the VM, but most importantly has work
done to the queue elevator code, thats probably whats doing most of the
work (throttling big writers) of seeing better overall system performance.
On Sun, Apr 14, 2002 at 03:15:39PM -0400, Lamar Owen wrote:
ISTM that improving interactive performance would also improve multiuser
performance in a server, as low latency and kernel preemption can increase
multiuser server responsiveness.
I doubt any performance will increase, either on a multiuser or on a
singleuser system.
Having faster response on mouse clicks or keyboard input doesn't translate
on better overall performance, the user just has the felling that it's so.
As an example, a part of those patches causes brakes in the middle of some
loops (saving buffers to disk, etc). Then other applications that don't
depend on disk activity can have change to run, so the system seems
faster, it's more responsive. But it won't actually be faster, the system
still has to lock again and continue saving the buffers. Actually, in this
case there will be an overhead caused by checking if the kernel should
brake.
However, both projects review the Linux code, and may find, if they
haven't already, some places were a finer locking may be used, giving a
better performance in a SMP system. But it could also break some
integrity.
Those patches are not recomended for a server, and now I'm curious to
check if the -enterprise configuration has them active.
Did you happen to report it to Red Hat's Skipjack list, or to
bugzilla.redhat.com/bugzilla? Helps make a better dist!
Alas, a bug report saying: the system crashed, I can't login remotely,
doesn't help a lot...
Regards,
Luciano Rocha
--
Luciano Rocha, strange@nsk.yi.org
The trouble with computers is that they do what you tell them, not what
you want.
-- D. Cohen
Lamar
RPMs for 7.2.1 are immediately available for download from
ftp://ftp.postgresql.org/pub/binary/v7.2.1/RPMS
Is the attached message one of the patches that has yet
to be applied? Without this patch the RPM needs some
patching to get it to compile on a MIPS machine.
make -C lmgr SUBSYS.o
make[4]: Entering directory
`/ws/whunter/dev/rpm/BUILD/postgresql-7.2.1/src/backend/storage/lmgr'
[snip]
gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations
-I../../../../src/include -I/usr/kerberos/include -c -o s_lock.o s_lock.c
s_lock.c:170: warning: `tas_dummy' defined but not used
/tmp/ccuQB808.s: Assembler messages:
/tmp/ccuQB808.s:173: Error: opcode not supported on this processor:
R3000 (MIPS1) `ll $14,0($4)'
/tmp/ccuQB808.s:175: Error: opcode not supported on this processor:
R3000 (MIPS1) `sc $15,0($4)'
Warwick
PS: forgive me if this is the wrong place to send this.
--
Warwick Hunter Agile TV Corporation
Voice: +61 7 5584 5912 Fax: +61 7 5575 9550
mailto:whunter@oz.agile.tv http://www.agile.tv
Attachments:
imap-message://whunter@surfers.oz.agile.tv/tools/pgsql#1message/rfc822; name="imap-message://whunter@surfers.oz.agile.tv/tools/pgsql#1"Download
Return-Path: <pgsql-hackers-owner+M20576@postgresql.org>
Received: from cart.mp.agile.tv (cart.mp.agile.tv [192.168.0.4])
by surfers.oz.agile.tv (8.11.6/8.11.2) with ESMTP id g2R9pWE28921
for <whunter@oz.agile.tv>; Wed, 27 Mar 2002 19:51:32 +1000
Received: from gatekeeper.agile.tv (ns1.agile.tv [64.232.86.197])
by cart.mp.agile.tv (8.11.6/emg20020209-int) with ESMTP id g2R9pVH11035
for <whunter@oz.agile.tv>; Wed, 27 Mar 2002 01:51:31 -0800
Received: from postgresql.org (postgresql.org [64.49.215.8])
by gatekeeper.agile.tv (8.11.0/emg20010629-ext) with ESMTP id
g2R9pUY02444
for <whunter@oz.agile.tv>; Wed, 27 Mar 2002 01:51:31 -0800
Received: from postgresql.org (postgresql.org [64.49.215.8])
by postgresql.org (Postfix) with SMTP
id 031F6475E9A; Wed, 27 Mar 2002 04:47:40 -0500 (EST)
Received: from anchor-post-36.mail.demon.net (anchor-post-36.mail.demon.net
[194.217.242.94])
by postgresql.org (Postfix) with ESMTP id 37948475B54
for <pgsql-hackers@postgresql.org>;
Wed, 27 Mar 2002 04:46:15 -0500 (EST)
Received: from lfix.demon.co.uk ([158.152.59.127] helo=linda.lfix.co.uk)
by anchor-post-36.mail.demon.net with esmtp (Exim 3.35 #1)
id 16qA0U-000G0E-0a; Wed, 27 Mar 2002 09:46:15 +0000
Received: from localhost ([127.0.0.1] helo=localhost.localdomain ident=olly)
by linda.lfix.co.uk with esmtp (Exim 3.35 #1 (Debian))
id 16qA0L-0002BF-00; Wed, 27 Mar 2002 09:46:05 +0000
Subject: [HACKERS] Linux/mips compile: [Fwd: Bug#139003: a little bit more is
needed...]
From: Oliver Elphick <olly@lfix.co.uk>
To: pgsql-hackers@postgresql.org
Cc: rmurray@debian.org
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="=-Zd+0ZcrpBCpp9VY6uMyv"
X-Mailer: Evolution/1.0.2
Date: 27 Mar 2002 09:46:04 +0000
Message-Id: <1017222365.1228.274.camel@linda>
Mime-Version: 1.0
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
--=-Zd+0ZcrpBCpp9VY6uMyv
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
-----Forwarded Message-----
From: rmurray@debian.org
To: 139003@bugs.debian.org
Cc: control@bugs.debian.org
Subject: Bug#139003: a little bit more is needed...
Date: 27 Mar 2002 00:21:18 -0800
reopen 139003
thanks
Looks like a small patch is needed as well to do the right thing on Linux.
The patch enables the mips2 ISA for the ll/sc operations, and then restores
it when done. The kernel/libc emulation code will take over on CPUs without
ll/sc, and on CPUs with it, it'll use the operations provided by the CPU.
Combined with the earlier fix (removing -mips2), postgresql builds again on
mips and mipsel. The patch is against 7.2-7.
diff -urN postgresql-7.2/src/backend/storage/lmgr/s_lock.c postgresql-7.2.f=
ixed/src/backend/storage/lmgr/s_lock.c
--- postgresql-7.2/src/backend/storage/lmgr/s_lock.c Mon Nov 5 18:46:28 20=
01
+++ postgresql-7.2.fixed/src/backend/storage/lmgr/s_lock.c Wed Mar 27 07:46=
:59 2002
@@ -173,9 +173,12 @@
.global tas \n\
tas: \n\
.frame $sp, 0, $31 \n\
+ .set push \n\
+ .set mips2 \n\n
ll $14, 0($4) \n\
or $15, $14, 1 \n\
sc $15, 0($4) \n\
+ .set pop \n\
beq $15, 0, fail\n\
bne $14, 0, fail\n\
li $2, 0 \n\
--=-Zd+0ZcrpBCpp9VY6uMyv
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQA8oZTcYU1MND4dDBwRAoauAJ4t+mR9gTqOYDdaDKLKytoPj811YwCgz/4k
D34xRYM+se1wuNOGGQST3Yo=
=Hmbh
-----END PGP SIGNATURE-----
--=-Zd+0ZcrpBCpp9VY6uMyv--