Re: [PERFORM] Sun performance - Major discovery! - Mailing list pgsql-hackers

Isn't it great how you have the same directory on every host so you can
download once and run the same tests easily.


Neil Conway wrote:
> $ uname -a
> Linux spe170 2.4.17-64 #1 Sat Mar 16 17:31:44 MST 2002 parisc64 unknown
> $ gcc --version
> 3.0.4
>
> 'make check' passes

I didn't know there was a pa-risc-64 chip.

> BTW, this platform doesn't have any code written for native spinlocks.
>
> (4)
>
> $ uname -a
> Linux spe156 2.4.18-mckinley-smp #1 SMP Thu Jul 11 12:51:02 MDT 2002
> ia64 unknown
> $ gcc --version
>
> When you compile PostgreSQL without changing the CFLAGS configure picks,
> the initdb required for 'make check' fails with:
>
> [...]
> initializing pg_depend... ok
> creating system views... ok
> loading pg_description... ok
> creating conversions... ERROR:  could not identify operator 679
>
> I tried to compile PostgreSQL with CFLAGS='-O0' to see if the above
> resulted from an optimization-induced compiler error, but I got the
> following error:
>
> $ gcc -O0 -Wall -Wmissing-prototypes -Wmissing-declarations
> -I../../../../src/include -D_GNU_SOURCE   -c -o xlog.o xlog.c
> ../../../../src/include/storage/s_lock.h: In function `tas':
> ../../../../src/include/storage/s_lock.h:125: error: inconsistent
> operand constraints in an `asm'
>
> Whereas this works fine:
>
> $ gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations
> -I../../../../src/include -D_GNU_SOURCE   -c -o xlog.o xlog.c
> $
>
> BTW, line 138 of s_lock.h is:
>
> #if defined(__arm__) || defined(__arm__)

Fix just committed.  Thanks.

> That seems a little redundant.
>
> Anyway, I tried running initdb after compiling all of pgsql with "-O0',
> except for the files that included s_lock.h, but make check still
> failed:
>
> creating information schema... ok
> vacuuming database template1...
> /house/neilc/pgsql/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/initdb: line 882: 22035 Segmentation
fault     (core dumped) "$PGPATH"/postgres $PGSQL_OPT template1 >/dev/null  <<EOF 
> ANALYZE;
> VACUUM FULL FREEZE;
> EOF
>
> The core file seems to indicate a stack overflow due to an infinitely
> recursive function:
>
> (gdb) bt 25
> #0  0x4000000000645dc0 in hash_search ()
> #1  0x4000000000616930 in RelationSysNameCacheGetRelation ()
> #2  0x4000000000616db0 in RelationSysNameGetRelation ()
> #3  0x4000000000082e40 in relation_openr ()
> #4  0x4000000000083910 in heap_openr ()
> #5  0x400000000060e6b0 in ScanPgRelation ()
> #6  0x4000000000611d60 in RelationBuildDesc ()
> #7  0x4000000000616e70 in RelationSysNameGetRelation ()
> #8  0x4000000000082e40 in relation_openr ()
> #9  0x4000000000083910 in heap_openr ()
> #10 0x400000000060e6b0 in ScanPgRelation ()
> #11 0x4000000000611d60 in RelationBuildDesc ()
> #12 0x4000000000616e70 in RelationSysNameGetRelation ()
> #13 0x4000000000082e40 in relation_openr ()
> #14 0x4000000000083910 in heap_openr ()
> #15 0x400000000060e6b0 in ScanPgRelation ()
> #16 0x4000000000611d60 in RelationBuildDesc ()
> #17 0x4000000000616e70 in RelationSysNameGetRelation ()
> #18 0x4000000000082e40 in relation_openr ()
> #19 0x4000000000083910 in heap_openr ()
> #20 0x400000000060e6b0 in ScanPgRelation ()
> #21 0x4000000000611d60 in RelationBuildDesc ()
> #22 0x4000000000616e70 in RelationSysNameGetRelation ()
> #23 0x4000000000082e40 in relation_openr ()
> #24 0x4000000000083910 in heap_openr ()
> (More stack frames follow...)
>
> (It also dumps core in the same place during initdb if CFLAGS='-O' is
> specified.)
>
> So it looks like the Itanium port is a little broken. Does anyone have
> an idea what needs to be done to fix it?

My guess is that the compiler itself is broken --- what else could it
be?

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073