Re: [HACKERS] Feb. 15 snapshot doesn't compile on alpha / Digital Unix (fwd) - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] Feb. 15 snapshot doesn't compile on alpha / Digital Unix (fwd)
Date
Msg-id 199802181557.KAA17350@candle.pha.pa.us
Whole thread Raw
In response to Feb. 15 snapshot doesn't compile on alpha / Digital Unix (fwd)  ("Pedro J. Lobo" <pjlobo@euitt.upm.es>)
List pgsql-hackers
OK, where are we with Alpha now?  Dec Unix and Alpha Linux users, what
is your status.  Is anyone geting through initdb, and if so, how?


> Hi, all.
>
> I'm forwarding this message I posted to psql-ports, because I've seen no
> answer on it, and the D-day approaches...
>
> ---------- Forwarded message ----------
> Date: Mon, 16 Feb 1998 12:48:49 +0100 (MET)
> From: "Pedro J. Lobo" <pjlobo@euitt.upm.es>
> To: PostgreSQL ports mailing list <pgsql-ports@postgresql.org>
> Subject: Feb. 15 snapshot doesn't compile on alpha / Digital Unix
>
> Hi, folks.
>
> The good news: I compiled 6.3 beta on Digital Unix 3.2c using the DEC C
> compiler.
>
> The bad news: It doesn't work :-(
>
> It compiles and installs well, but initdb fails. This is the output
> message:
>
> ------------------------------------------------------------
> initdb: using /usr/local/pgsql.beta/lib/local1_template1.bki.source as
> input to create the template database.
> initdb: using /usr/local/pgsql.beta/lib/global1.bki.source as input to
> create the global classes.
> initdb: using /usr/local/pgsql.beta/lib/pg_hba.conf.sample as the
> host-based authentication control file.
>
> We are initializing the database system with username pgbeta (uid=104).
> This user will own all the files and must also own the server process.
>
> Creating Postgres database system directory /usr/local/pgsql.beta/data
>
> Creating Postgres database system directory /usr/local/pgsql.beta/data/base
>
> initdb: creating template database in /usr/local/pgsql.beta/data/base/template1
> Running: postgres -boot -C -F -D/usr/local/pgsql.beta/data -Q template1
> ERROR:  BuildFuncTupleDesc: function mkoidname(opaque, opaque) does not exist
> ERROR:  BuildFuncTupleDesc: function mkoidname(opaque, opaque) does not exist
> longjmp or siglongjmp function used outside of saved context
> /usr/local/pgsql.beta/bin/initdb: 420 Abort - core dumped
> initdb: could not create template database
> initdb: cleaning up by wiping out /usr/local/pgsql.beta/data/base/template1
> -----------------------------------------------------------
>
> This is the GDB stack trace from the core file:
>
>
> ----------------------------------------------------------
> GDB 4.16 (alpha-dec-osf3.2), Copyright 1996 Free Software Foundation, Inc...
> Core was generated by `postgres'.
> Program terminated with signal 6, IOT/Abort trap.
> Reading symbols from /usr/shlib/libm.so...done.
> Reading symbols from /usr/shlib/libcurses.so...done.
> Reading symbols from /usr/shlib/libc.so...done.
> Reading symbols from /usr/lib/nls/loc//es_ES.ISO8859-1...done.
> #0  0x3ff8010cf28 in kill ()
> (gdb) where
> #0  0x3ff8010cf28 in kill ()
> #1  0x3ff801218f4 in raise ()
> #2  0x3ff8010fd44 in abort ()
> #3  0x3ff80102e20 in _longjmp ()
> #4  0x3ff80105778 in siglongjmp ()
> #5  0x120144d24 in handle_warn (postgres_signal_arg=1) at postgres.c:736
> #6  <signal handler called>
> #7  0x3ff8010cf28 in kill ()
> #8  0x12018deb8 in elog (lev=-1,
>     fmt=0x14002f8d8 "%s: function %s(%s) does not exist", ...=0x140011428)
>     at elog.c:180
> #9  0x12010ddd4 in func_error (caller=0x140011428 "BuildFuncTupleDesc",
>     funcname=0x11ffff260 "mkoidname", nargs=2, argtypes=0x11ffff23c)
>     at parse_func.c:1307
> #10 0x120074114 in BuildFuncTupleDesc (funcInfo=0x11ffff238) at index.c:298
> #11 0x120075998 in index_create (heapRelationName=0x1401bba50 "pg_attribute",
>     indexRelationName=0x1401dc730 "pg_attribute_relid_attnam_index",
>     funcInfo=0x11ffff238, attributeList=0x0, accessMethodObjectId=403,
>     numatts=1, attNums=0x1401dc9c0, classObjectId=0x1401dc9f0,
>     parameterCount=0, parameter=0x0, predicate=0x0, islossy=0 '\000',
>     unique=0 '\000') at index.c:1114
> #12 0x1200860a4 in DefineIndex (heapRelationName=0x1401bba50 "pg_attribute",
>     indexRelationName=0x1401dc730 "pg_attribute_relid_attnam_index",
>     accessMethodName=0x1401db830 "btree", attributeList=0x1401e0a60,
>     parameterList=0x0, unique=0 '\000', predicate=0x0, rangetable=0x0)
>     at defind.c:190
> #13 0x12006b580 in Int_yyparse () at /usr/local/share/bison.simple:234
> #14 0x12006e80c in BootstrapMain (argc=6, argv=0x11ffffcb0) at bootstrap.c:446
> #15 0x1200c51b0 in main (argc=7, argv=0x11ffffca8) at main.c:94
> --------------------------------------------------------------
>
>
> I have no knowledge of postgres internals, but I have experience in C/C++
> programming (and debugging) and can help if someone gives me a clue. The
> same hardware/OS/compiler combination works well with 6.2.1p6.
>
> In case it matters, this is the configure command that I've used:
>
> ./configure --prefix=/usr/local/pgsql.beta --enable-locale
> --with-pgport=5440 --enable-cassert --with-compiler=cc
>
> I have my production database (6.2.1p6) running on the same machine on the
> standard port (5432), but I don't think it has any adverse effect. In
> fact, postgres -boot doesn't do any socket communications, does it? The
> production database is stored completely on another tree
> (/usr/local/pgsql instead of /usr/local/pgsql.beta).
>
> BTW, I had to patch 'configure' to handle --with-compiler correctly. This
> is an old problem, and I will report it more extensively in another
> message.
>
>
> -------------------------------------------------------------------
> Pedro Jos� Lobo Perea                   Tel:    +34 1 336 78 19
> Centro de C�lculo                       Fax:    +34 1 331 92 29
> EUIT Telecomunicaci�n - UPM             e-mail: pjlobo@euitt.upm.es
>
>
>
>


--
Bruce Momjian
maillist@candle.pha.pa.us

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: [HACKERS] Open 6.3 issues (fwd)
Next
From: Mattias Kregert
Date:
Subject: Re: AW: [HACKERS] Re: Subselects open issue Nr. NEW