Re: [HACKERS] initdb problem again

From: Keith Parks <emkxp01(at)mtcc(dot)demon(dot)co(dot)uk>
To: meskes(at)online-club(dot)de, maillist(at)candle(dot)pha(dot)pa(dot)us
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] initdb problem again
Date: 1998-08-20 20:52:50
Message-ID: 199808202052.VAA18405@mtcc.demon.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)candle(dot)pha(dot)pa(dot)us>
>
> What bugs me is how the initdb and regression tests can run fine on
> BSDI, but fail other places.
>

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1998-08-20 22:09:22 Re: [HACKERS] initdb problem again
Previous Message Bruce Momjian 1998-08-20 18:06:59 Re: [HACKERS] weird problem with latest cvs