Bug 7330 - postgresql will not initdb or work at all in Linux/Ultrasparc machines
postgresql will not initdb or work at all in Linux/Ultrasparc machines
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: postgresql (Show other bugs)
6.1
sparc Linux
medium Severity high
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
:
: 8383 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-11-25 09:18 EST by Silvio
Modified: 2008-05-01 11:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-01-13 16:52:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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 09:20 EST, Silvio
no flags Details | Diff

  None (edit)
Description Silvio 1999-11-25 09:18:21 EST
============================================================================
                        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 09:20:59 EST
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 10:41:59 EST
*** Bug 8383 has been marked as a duplicate of this bug. ***
Comment 3 Jeff Johnson 2000-01-13 16:52:59 EST
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.