Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 7330 - postgresql will not initdb or work at all in Linux/Ultrasparc machines
Summary: postgresql will not initdb or work at all in Linux/Ultrasparc machines
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: postgresql
Version: 6.1
Hardware: sparc
OS: Linux
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact:
: 8383 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 1999-11-25 14:18 UTC by Silvio
Modified: 2008-05-01 15:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2000-01-13 21:52:37 UTC

Attachments (Terms of Use)
Patch to apply to any Postgres version in order for it to work in Ultrasparc/Linux (deleted)
1999-11-25 14:20 UTC, Silvio
no flags Details | Diff

Description Silvio 1999-11-25 14:18:21 UTC
                        POSTGRESQL BUG REPORT TEMPLATE

Your name               :       Silvio Macedo
Your email address      :


System Configuration
  Architecture (example: Intel Pentium)         : Sun Ultrasparc 1
(143Mhz, 2.1 Gb disk, 64Mb RAM)

  Operating System (example: Linux 2.0.26 ELF)  : Linux 2.2.12 ELF, (RH6.1)

  PostgreSQL version (example: PostgreSQL-6.5.3): PostgreSQL-6.5.3/2/SNAP

  Compiler used (example:  gcc 2.8.0)           : gcc version egcs-2.91.66
1999$                                                  (comes with RH6.1)
                                                  GNUlibc 2.1.2

Please enter a FULL description of your problem:

In 64 bit machines like the Ultraparc, strncmp can return -256.
In src/backend/utils/adt/name.c you do:
                return (bool) strncmp(arg1->data, arg2->data, NAMEDATALEN)
== 0;
In this way you are casting strncmp to bool, and not the comparison.

This is the description of the consequences, that I sent before I
discovered the problem:
(I am giving a really detailed description to maximize the chances that
you find the solution to my problem)

I have installed postgres many times in several Linux/Intel systems.

Now, I am trying to install Pg 6.5.3 ( or any other version of Pg) in a
Linux/(ultra)Sparc system. The system seems stable in any task other than
postgres stuff, but when I run initdb, it always dies with and error
about :
"Attribute 'aggtransfn1' is repeated."

I have downloaded source distribution PG 6.5.3, PG Snapshot, PG 6.5.2
and RPM binaries of Pg from RedHat 6.1 distribution and even SRPMS.

In all of them, after compiling and/or installing, when I do the initdb
-d, the script dies with this message:

> <aggname name>
<aggowner int4>
<aggtransfn1 regproc>
<aggtransfn2 regproc>
<aggfinalfn regproc>
<aggbasetype oid>
<aggtranstype1 oid>
<aggtranstype2 oid>
<aggfinaltype oid>
<agginitval1 text>
<agginitval2 text>
> ERROR:  Attribute 'aggtransfn1' is repeated
ERROR:  Attribute 'aggtransfn1' is repeated
initdb: could not create template database
initdb: cleaning up by wiping out /usr/local/pgsql/data/base/template1

I have also tried initdb with the full command line, etc..

This happens with all the versions of Pg that I have tested:
   Pg Snapshot 22 Nov
Pg 6.5.3,
Pg 6.5.2,
Binaries in RPM from RedHat 6.1 Sparc
Source SRPM from '' ''

Then, I investigated the problem deeper, and deeper.
If I remove aggtransfn2 from the local1.????.bki.source, it gives the same
error in agginitval2.

I replaced the ERROR with a NOTICE on the elog on the file
src/backend/catalog/heap.c in the function CheckAttributeNames() and
everything went ok until I started regression tests. Lots of 'failed'
appeared in the char/string related tests, and those were real problems,
because I checked it myself (not just little differences); the backend
closed connection in some tests.

 I then added some lines in the src/backend/catalog/heap.c to see if the
strings were read ok and if NAMEDATALEN was ok. Yes, they were.
aggtransfn1 was compared to aggransfn2 by a call to nameeq(), and this
function returned that they were equal (obviously they differ on the last

Then, finally I replaced the call to nameeq to a direct strncmp() between
both tuple->data's and it worked. The regression tests still failed.

Maybe there is a problem in the strncmp libraries in my system ? oh no...

[PS: The source of this problem as I wrote above, is in Postgres name.c
file, in nameeq() ]

Please describe a way to repeat the problem.   Please try to provide a
concise reproducible example, if at all possible:

configure --with-x --with-tcl --with-template=linux_sparc
make install
cd /usr/local/pgsql

If you know how this problem might be fixed, list the solution below:
I send both diff -f and diff -u in attach

--- postgresql-6.5.3/src/backend/utils/adt/name.c       Mon Aug  2 06:24:55
1999+++    Thu Nov 25
11:53:39 1999@@ -87,7 +87,7 @@
        if (!arg1 || !arg2)
                return 0;
-               return (bool) strncmp(arg1->data, arg2->data, NAMEDATALEN)
== 0;+               return (bool) (strncmp(arg1->data, arg2->data,


Comment 1 Silvio 1999-11-25 14:20:59 UTC
Created attachment 16 [details]
Patch to apply to any Postgres version in order for it to work in Ultrasparc/Linux

Comment 2 Jeff Johnson 2000-01-12 15:41:59 UTC
*** Bug 8383 has been marked as a duplicate of this bug. ***

Comment 3 Jeff Johnson 2000-01-13 21:52:59 UTC
Patch added in postgresql-6.5.3-4. Thanks for the report.

Note You need to log in before you can comment on or make changes to this bug.