I'm experiencing a strange problem when playing with the
bench scripts. (No postmaster running).

Platform SPARC Linux 2.0.36, latest CVS.

If I do:-

[postgres@sparclinux bench]$ rm -rf /usr/local/pgsql/data/
[postgres@sparclinux bench]$ initdb

We are initializing the database system with username postgres (uid=900).
This user will own all the files and must also own the server process.

Creating Postgres database system directory /usr/local/pgsql/data

Creating Postgres database system directory /usr/local/pgsql/data/base

Creating template database in /usr/local/pgsql/data/base/template1

Creating global classes in /usr/local/pgsql/data/base

Adding template1 database to pg_database...

Vacuuming template1
Creating public pg_user view
Creating view pg_rules
Creating view pg_views
Creating view pg_tables
Creating view pg_indexes
Loading pg_description
[postgres@sparclinux bench]$  postgres -D/usr/local/pgsql/data template1

POSTGRES backend interactive interface
$Revision: 1.115 $ $Date: 1999/05/22 17:47:49 $

backend> create database bench

The command just hangs.

If I run under a debugger I can see the following backtrace:-

(gdb) cont
Continuing.

Program received signal SIGINT, Interrupt.
SpinAcquire (lockid=5) at spin.c:109
109             S_LOCK(&(slckP->locklock));
(gdb) bt
#0  SpinAcquire (lockid=5) at spin.c:109
#1  0xd0b80 in LockAcquire (lockmethod=1, locktag=0xefff6e00, lockmode=1) at lock.c:530
#2  0xd02c4 in LockRelation (relation=0x2c9b18, lockmode=1) at lmgr.c:185
#3  0x104d8c in scan_pg_rel_ind (buildinfo={infotype = 2, i = {info_id = 1400920, info_name = 0x156058 "pg_type_oid_index"}})
    at relcache.c:394
#4  0x104c68 in ScanPgRelation (buildinfo={infotype = 2, i = {info_id = 1400920, info_name = 0x156058 "pg_type_oid_index"}})
    at relcache.c:316
#5  0x1059f0 in RelationBuildDesc (buildinfo={infotype = 2, i = {info_id = 1400920, info_name = 0x156058 "pg_type_oid_index"}})
    at relcache.c:802
#6  0x1061cc in RelationNameGetRelation (relationName=0x156058 "pg_type_oid_index") at relcache.c:1220
#7  0x3d0d4 in index_openr (relationName=0x156058 "pg_type_oid_index") at indexam.c:153
#8  0x102d5c in CatalogCacheInitializeCache (cache=0x2ec018, relation=0x2cadb0) at catcache.c:247
#9  0x103c1c in SearchSysCache (cache=0x2ec018, v1=705, v2=0, v3=0, v4=0) at catcache.c:834
#10 0x107d8c in SearchSysCacheTuple (cacheId=13, key1=705, key2=0, key3=0, key4=0) at syscache.c:507
#11 0x96db4 in typeidType (id=705) at parse_type.c:67
#12 0x955a8 in make_const (value=0x30e390) at parse_node.c:421
#13 0x91cdc in transformExpr (pstate=0x30e590, expr=0x30e388, precedence=1) at parse_expr.c:105
#14 0x97ecc in MakeTargetEntryComplex (pstate=0x30e590, res=0x30e3b0) at parse_target.c:367
#15 0x98430 in transformTargetList (pstate=0x30e590, targetlist=0x30e3c8) at parse_target.c:574
#16 0x88078 in transformInsertStmt (pstate=0x30e590, stmt=0x30e530) at analyze.c:267
#17 0x87ee8 in transformStmt (pstate=0x30e590, parseTree=0x30e530) at analyze.c:180
#18 0x87c60 in parse_analyze (pl=0x30e578, parentParseState=0x0) at analyze.c:72
#19 0x905b4 in parser (str=0x1d7c00 "", typev=0x0, nargs=0) at parser.c:62
#20 0xd6f58 in pg_parse_and_plan (
    query_string=0xefffb8e0 "insert into pg_database (datname, datdba, encoding, datpath) values ('bench', '900', '0', 'bench');",
    typev=0x0, nargs=0, queryListP=0xefffb65c, dest=Debug, aclOverride=0 '\000') at postgres.c:454
#21 0xd7350 in pg_exec_query_dest (
    query_string=0xefffb8e0 "insert into pg_database (datname, datdba, encoding, datpath) values ('bench', '900', '0', 'bench');",
    dest=Debug, aclOverride=0 '\000') at postgres.c:664
#22 0x72228 in createdb (dbname=0x30e040 "bench", dbpath=0xefffb6e0 "bench", encoding=0, dest=Debug) at dbcommands.c:91
#23 0xd9e68 in ProcessUtility (parsetree=0x30e058, dest=Debug) at utility.c:560
#24 0xd7400 in pg_exec_query_dest (query_string=0xefffbcc8 "create database bench\n", dest=Debug, aclOverride=0 '\000') at 
postgres.c:704
#25 0xd7304 in pg_exec_query (query_string=0xefffbcc8 "create database bench\n") at postgres.c:642
#26 0xd86fc in PostgresMain (argc=3, argv=0xeffffd94, real_argc=3, real_argv=0xeffffd94) at postgres.c:1626
#27 0x87c24 in main (argc=3, argv=0xeffffd94) at main.c:103
(gdb)                                                                                            


Mon, 24 May 1999 17:11:01 +0100 (BST)
Keith Parks <emkxp01@mtcc.demon.co.uk>
Problem in S_LOCK?
I just tried initdb and:

	Vacuuming template1
	Creating public pg_user view
	Creating view pg_rules
	Creating view pg_views
	Creating view pg_tables
	Creating view pg_indexes
	Loading pg_description
	#$ aspg postgres -D /u/pg/data template1
	
	POSTGRES backend interactive interface 
	$Revision: 1.115 $ $Date: 1999/05/22 17:47:49 $
	
	backend> create database bench       
	blank
	         1: datname     (typeid = 19, len = 32, typmod = -1, byval = f)
	         2: datdba      (typeid = 23, len = 4, typmod = -1, byval = t)
	         3: encoding    (typeid = 23, len = 4, typmod = -1, byval = t)
	         4: datpath     (typeid = 25, len = -1, typmod = -1, byval = f)
	        ----
	backend> 

and it worked.


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 24 May 1999 17:07:04 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Problem in S_LOCK?
Keith Parks <emkxp01@mtcc.demon.co.uk> writes:
> Platform SPARC Linux 2.0.36, latest CVS.

SPARC Linux?  Didn't know there was such a thing.  You should look at
the machine-dependent assembly coding in s_lock.h and s_lock.c.  Perhaps
the #ifdefs are messed up such that the wrong bit of code is being
selected for your platform.  (We do have spinlock code for SPARC, IIRC,
but I wonder whether it gets selected if the platform name is linux ...)

If the failure just started appearing recently then this probably ain't
the answer :-(

			regards, tom lane

Mon, 24 May 1999 20:30:42 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Problem in S_LOCK? 