initdb problem again

What bugs me is how the initdb and regression tests can run fine on
BSDI, but fail other places.

Maybe someone gets an idea by looking at the stack trace at the moment of
the error message:

(gdb) where
#0 fmgr_info (procedureId=683, finfo=0x82154f4) at fmgr.c:179
#1 0x8162739 in CatalogCacheInitializeCache (cache=0x8215478,
relation=0x81f03b0) at catcache.c:217
#2 0x8163e3a in SearchSysCache (cache=0x8215478, v1=135759431, v2=1,
v3=3221222512, v4=0) at catcache.c:837
#3 0x8169076 in SearchSysCacheTuple (cacheId=8, key1=135759431, key2=1,
key3=3221222512, key4=0) at syscache.c:508
#4 0x8096869 in TypeCreate (typeName=0x82136a0 "pg_inherits",
relationOid=16536, internalSize=4, externalSize=4, typeType=99 'c',
typDelim=44 ',', inputProcedure=0x8178647 "int4in",
outputProcedure=0x817863f "int4out", receiveProcedure=0x8178647 "int4in",
sendProcedure=0x817863f "int4out", elementTypeName=0x0,
defaultTypeValue=0x817863d "-", passedByValue=1 '\001', alignment=105 'i')
at pg_type.c:408
#5 0x808e7ec in addNewRelationType (typeName=0x82136a0 "pg_inherits",
new_rel_oid=16536) at heap.c:724
#6 0x808e8c9 in heap_create_with_catalog (relname=0x82136a0 "pg_inherits",
tupdesc=0x82137a8, relkind=114 'r') at heap.c:798
#7 0x8089fae in Int_yyparse () at bootparse.y:182
#8 0x808c4d4 in BootstrapMain (argc=6, argv=0xbffffb18) at bootstrap.c:426
#9 0x80c8103 in main (argc=7, argv=0xbffffb14) at main.c:100

The structure cache points to starts with:

$7 = {relationId = 1255, indexId = 0, cc_relname = 0x819d780 "pg_proc",
cc_indname = 0x819d760 "pg_proc_proname_narg_type_index",
cc_iscanfunc = 0x8092760 <ProcedureNameIndexScan>, cc_tupdesc = 0x81f03f8,
id = 8, cc_ntup = 0, cc_maxtup = 300, cc_nkeys = 3, cc_size = 500, cc_key
= {
1, 7, 10, 0}, cc_klen = {32, 2, 32, 0}, cc_skey = {{sk_flags = 0,
sk_attno = 1, sk_procedure = 62, sk_func = {
fn_addr = 0x815bbb0 <nameeq>, fn_plhandler = 0, fn_oid = 62,
fn_nargs = 2}, sk_nargs = 2, sk_argument = 0}, {sk_flags = 0,
sk_attno = 7, sk_procedure = 63, sk_func = {
fn_addr = 0x8158c60 <int2eq>, fn_plhandler = 0, fn_oid = 63,
fn_nargs = 2}, sk_nargs = 2, sk_argument = 0}, {sk_flags = 0,
sk_attno = 10, sk_procedure = 683, sk_func = {fn_addr = 0,
fn_plhandler = 0, fn_oid = 683, fn_nargs = 0}, sk_nargs = 0,
sk_argument = 0}, {sk_flags = 0, sk_attno = 0, sk_procedure = 0,
sk_func = {fn_addr = 0, fn_plhandler = 0, fn_oid = 0, fn_nargs = 0},
sk_nargs = 0, sk_argument = 0}}, cc_next = 0x8213a78,
cc_lrulist = 0x82153d8, cc_cache = {0x8215d10, 0x8215d18, 0x8215d20,
0x8215d28, 0x8215d30, 0x8215d38, 0x8215d40, 0x8215d48, 0x8215d50,
...

I am surprised that cache->cc_skey contains an addr and a number of
arguments in sk_func for each function except 683 that causes the error
message.

Michael
--
Michael Meskes meskes@online-club.de, meskes@debian.org
Go SF49ers! Go Rhein Fire! Use Debian GNU/Linux!

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Hi all,

initdb seems to run without problems on my system but after starting
the postmaster I start to see some problems.

A simple "select * from pg_user;" gives an error:-

ERROR: Relation pg_user does not have attribute usename

OK pg_user is a VIEW/RULE but it is interesting that initdb
creates a table in the process of creating the view.

If I try to create a table myself the backend dies as before
with a SIGSEGV. (see thread [HACKERS] Broken PostgreSQL (latest CVS) )

Here's what's happening with the select from pg_user.

Keith.

Program received signal SIGHUP, Hangup.
0xe00f4f20 in __kill ()
(gdb) bt
#0 0xe00f4f20 in __kill ()
#1 0xd4bd0 in elog (lev=-1,
fmt=0xefffac50 "ERROR: Relation pg_user does not have attribute usename\n")
at elog.c:181
#2 0x92428 in make_var (pstate=0x1, relid=17184, refname=0x15baf0 "pg_user",
attrname=0x15b330 "usename") at parse_node.c:232
#3 0x939c0 in expandAll (pstate=0x159690, relname=0x15b330 "usename",
refname=0x15baf0 "pg_user", this_resno=0x159690) at parse_relation.c:267
#4 0x95690 in ExpandAllTables (pstate=0x159690) at parse_target.c:816
#5 0x94e84 in transformTargetList (pstate=0x159690, targetlist=0x15bbd0)
at parse_target.c:347
#6 0x8838c in transformSelectStmt (pstate=0x159690, stmt=0x1596d0) at
analyze.c:828
#7 0x876b0 in transformStmt (pstate=0x159690, parseTree=0x1596d0) at
analyze.c:190
#8 0x8740c in parse_analyze (pl=0x15bb30, parentParseState=0x0) at analyze.c:76
#9 0x8e624 in parser (str=0x0, typev=0x0, nargs=0) at parser.c:64
#10 0xaea24 in pg_parse_and_plan (
query_string=0xefffd1a0 " select * from pg_user;", typev=0x0, nargs=0,
queryListP=0xefffd0bc, dest=Remote) at postgres.c:401
#11 0xaee08 in pg_exec_query_dest (
query_string=0xefffd1a0 " select * from pg_user;", dest=Remote)
at postgres.c:617
#12 0xaede4 in pg_exec_query (query_string=0xefffd1a0 " select * from pg_user;")
at postgres.c:602
#13 0xafd70 in PostgresMain (argc=1159168, argv=0xeffff1a0, real_argc=10,
real_argv=0xeffffd84) at postgres.c:1429
#14 0x98c54 in DoBackend (port=0xfd400) at postmaster.c:1412
#15 0x98690 in BackendStartup (port=0x15cc00) at postmaster.c:1191
#16 0x97cbc in ServerLoop () at postmaster.c:725
#17 0x97814 in PostmasterMain (argc=0, argv=0xeffffd84) at postmaster.c:534
#18 0x6c214 in main (argc=10, argv=0xeffffd84) at main.c:93
(gdb) list parse_node.c:232
227
228 vnum = refnameRangeTablePosn(pstate, refname, &sublevels_up);
229
230 attid = get_attnum(relid, attrname);
231 if (attid == InvalidAttrNumber)
232 elog(ERROR, "Relation %s does not have attribute %s",
233 refname, attrname);
234 vartypeid = get_atttype(relid, attid);
235 type_mod = get_atttypmod(relid, attid);
236

Bruce Momjian <maillist@candle.pha.pa.us>

Hi all,

initdb seems to run without problems on my system but after starting
the postmaster I start to see some problems.

A simple "select * from pg_user;" gives an error:-

ERROR: Relation pg_user does not have attribute usename

OK pg_user is a VIEW/RULE but it is interesting that initdb
creates a table in the process of creating the view.

If I try to create a table myself the backend dies as before
with a SIGSEGV. (see thread [HACKERS] Broken PostgreSQL (latest CVS) )

Here's what's happening with the select from pg_user.

Keith.

OK, I am committing a fix for index destruction. That may help some
people.

Not sure why the initdb is behaving differently on different platforms,
especially when it works here. I will keep looking.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)