PostregSQL 6.5.3 on Linux RedHat 6.1/Ultra1 Sparc (sun4u)
Hi,
I compiled PgSQL 6.5.3 with the following procedure :
# tar xvzf postgres...gz
# cd post*3/src
#./configure --prefix=/usr/local/pgsql --with-x --with-perl --enable-locale --with-pgport=1521
This fails because PgSQL was not able to recognize my system :
Linux zebra 2.2.12-42 #1 Fri Nov 12 13:03:33 EST 1999 sparc64 unknown
So, I defined a template that seems to be the better :
# ./configure --prefix=/usr/local/pgsql --with-x --with-perl --enable-locale --with-pgport=1521 --with-template=linux_sparc
...
# make
All compiled normally
# make install
Install was also perfect.
Then I prepared Pgsql :
# chown -R pgsql:pgsql /usr/local/pgsql /var/pgsql
# vi ~pgsql/.profile, to get :
PGLIB=/usr/local/pgsql/lib
PGDATA=/var/pgsql/data
export PGLIB PGDATA
PATH=$PATH:/usr/local/pgsql/bin
LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib:/usr/local/pgsql/lib
export LD_LIBRARY_PATH
Then I installed the template1 database to starting doing my tests :
su - pgsql
Environment is set correctly
$ initdb --username=pgsql
We are initializing the database system with username pgsql (uid=502).
This user will own all the files and must also own the server process.
Creating Postgres database system directory /var/pgsql/data
Creating Postgres database system directory /var/pgsql/data/base
Creating template database in /var/pgsql/data/base/template1
ERROR: Attribute 'aggtransfn1' is repeated
ERROR: Attribute 'aggtransfn1' is repeated
initdb: could not create template database
initdb: cleaning up by wiping out /var/pgsql/data/base/template1
And here we are, This is a typical bug report :)
My machine is an old Ultra 1 (143 MHz), with prom 3.11, and Sparc 64 architecture.
64 MB RAM, and 2x2GB SCSI disks.
Linux was installed just removing some packages, no changes on system from
RedHat 6.1 (kernel, ...).
I use the same procedure under Linux or Solaris Sparc, and everything was Ok.
Can you help ?
Regards
Laurent LEVIER
IT Systems & Networks, Unix System Engineer
Security Specialist
Argosnet Security Server : http://www.Argosnet.com
"Le Veilleur Technologique", "The Technology Watcher"
From bouncefilter Tue Dec 21 08:17:13 1999
Received: from alert.infoplease.com ([208.222.166.25])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA25659
for <pgsql-general@postgreSQL.org>;
Tue, 21 Dec 1999 08:16:42 -0500 (EST)
(envelope-from kdebisschop@range.infoplease.com)
Received: from skillet.infoplease.com (skillet [10.0.1.212])
by alert.infoplease.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27829
for <pgsql-general@postgreSQL.org>;
Tue, 21 Dec 1999 08:16:10 -0500 (EST)
Received: (from kdebisschop@localhost)
by skillet.infoplease.com (8.9.3/8.9.1) id IAA01837;
Tue, 21 Dec 1999 08:16:11 -0500
Date: Tue, 21 Dec 1999 08:16:11 -0500
Message-Id: <199912211316.IAA01837@skillet.infoplease.com>
X-Authentication-Warning: skillet.infoplease.com: kdebisschop set sender to
kdebisschop@spaceheater.infoplease.com using -f
From: Karl DeBisschop <kdebisschop@range.infoplease.com>
To: pgsql-general@postgreSQL.org
In-reply-to: <8703.945457153@sss.pgh.pa.us> (message from Tom Lane on Fri, 17
Dec 1999 13:59:13 -0500)
Subject: Cannot index large table in 6.5.3 on Linux
Reply-to: kdebisschop@range.infoplease.com
References: <8703.945457153@sss.pgh.pa.us>
This was originally posted on bugs, to no avail. Maybe someone else
in the general mailing list has had similar problems and can shed some
light.
Basically, the subject say it all. I am trying to index a text field
in a somehwhat large table (approx 1GB). We have had this database
running for over a year now, and we have never had this problem until
upgrading to 6.5.3. Most recently, we were running 6.5.1 and the
table indexed fine. We do a lot of inserts on the table each night,
so we drop the index first for performance reasons. Since upgrading
to 6.5.3, we have not been able to recreate the index (However, an
index on a char(1) field and a joint index on (date,integer) both do
work -- they generate 200000000 byte indexes.)
When we moved to 6.5.3, we vacuumed the database just to be make sure
there were no problems. That worked fine. It's just the creation
that seems to be the problem.
I have watched the process of creation. It seems to get most or all
of the way through the process - it creates an index file about the
size of the old one (~750000000 bytes). Then we get:
webusers=> CREATE INDEX zdaily_id ON daily (id);
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
We have lost the connection to the backend, so further processing is impossible. Terminating.
and everything is deleted.
The original 6.5.3 install was from the RPM. I have recompiled the
database on the machine in question, and still the same result. I
have tried both btree and hash indexes, still the same result. At
first, the table spanned two files. I moved old data out and shrunk
it to one file. Still the same result.
I have not been able to cause postmaster to generate a core when it
dies.
So no I'm stumped.
I am running on 1 dual-processor VA-linux machine:
Architecture (example: Intel Pentium) :
Intel Pentium III 450MHz x2 SMP
Operating System (example: Linux 2.0.26 ELF) :
Linux version 2.2.7-1.23smp (root@jiangsup.var.com) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP Thu Jul 8 15:23:01 PDT 1999
PostgreSQL version (example: PostgreSQL-6.5.2): PostgreSQL-6.5.3
(from postgresql-6.5.3-1.i386.rpm distributed by
www.POstgreSQL.org, then compiled on local machine)
Compiler used (example: gcc 2.8.0) :
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
I would appreciate any suggestions on additional possibilities for
diagnosis or repair.
--
Karl DeBisschop <kdebisschop@alert.infoplease.com>
617.832.0332 (Fax: 617.956.2696)
Information Please - your source for FREE online reference
http://www.infoplease.com - Your Ultimate Fact Finder
http://kids.infoplease.com - The Great Homework Helper
Netsaint Plugins Development
http://netsaintplug.sourceforge.net