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
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: postgresql
Version: 6.1
Hardware: sparc
OS: Linux
medium
high
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact:
URL:
Whiteboard:
: 8383 (view as bug list)
Depends On:
Blocks:
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:
Environment:
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 (371 bytes, patch)
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      : smacedo@ic.ac.uk

(or                        smacedo@inescn.pt)


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
character).

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
make install
cd /usr/local/pgsql
initdb




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+++ postgresql-6.5.3.my/src/backend/utils/adt/name.c    Thu Nov 25
11:53:39 1999@@ -87,7 +87,7 @@
        if (!arg1 || !arg2)
                return 0;
        else
-               return (bool) strncmp(arg1->data, arg2->data, NAMEDATALEN)
== 0;+               return (bool) (strncmp(arg1->data, arg2->data,
NAMEDATALEN) == $ }

 bool

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.