Hi, yes, I'm having trouble as well.
I'm crashing anytime I create a table, (-O2). I just tried the 8/29 snapshot.
I've got an environment set up now to try a few things.
Without -O2 it seem to be better. I see the same problem with
create function as you. Also many failures seem to the result
of some type not defined. Is that expected?
Sorry to jump in so late here.
Tom Szybist
szybist@boxhill.com
In message <199808291829.TAA25332@mtcc.demon.co.uk>, Keith Parks writes:
> If anyone has been watching my trials and tribulations building
> and running the latest CVS snapshot under S/Linux on a SUN
> SPARCstation IPX.
>
> The latest position is:-
>
> If I compile with optimization turned off (-O0 instead of -O2)
> I get an almost clean run of the regressin tests. Only the
> "create_function" tests fail unexpectedly.
>
> [postgres@sparclinux regress]$ psql regression
> Welcome to the POSTGRESQL interactive sql monitor:
> Please read the file COPYRIGHT for copyright terms of POSTGRESQL
>
> type \? for help on slash commands
> type \q to quit
> type \g or terminate with semicolon to execute query
> You are currently connected to the database: regression
>
> regression=> CREATE FUNCTION widget_in(opaque)
> regression-> RETURNS widget
> regression-> AS '/usr/local/pgsql/src/test/regress/input/../regress.so'
> regression-> LANGUAGE 'c';
> NOTICE: ProcedureCreate: type 'widget' is not yet defined
> pqReadData() -- backend closed the channel unexpectedly.
> This probably means the backend terminated abnormally before or while
> processing the request.
> We have lost the connection to the backend, so further processing is impossible.
> Terminating.
> [postgres@sparclinux regress]$
>
> The backtrace shows:-
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x44744 in GetIndexValue (tuple=0x25e210, hTupDesc=0x25e26c, attOff=0,
> attrNums=0x261944, fInfo=0x0,
> attNull=0xefffcbcf "") at indexam.c:404
> 404 returnVal = heap_getattr(tuple, attrNums[attOff],
> (gdb) bt
> #0 0x44744 in GetIndexValue (tuple=0x25e210, hTupDesc=0x25e26c, attOff=0,
> attrNums=0x261944, fInfo=0x0,
> attNull=0xefffcbcf "") at indexam.c:404
> #1 0x68e9c in FormIndexDatum (numberOfAttributes=1, attributeNumber=0x261944,
> heapTuple=0x25e210,
> heapDescriptor=0x25e26c, datum=0xefffccb8, nullv=0xefffcc58 " ",
> fInfo=0x0) at index.c:1284
> #2 0x69c38 in CatalogIndexInsert (idescs=0xefffcd30, nIndices=3,
> heapRelation=0x213b90, heapTuple=0x25e210)
> at indexing.c:154
> #3 0x6f344 in ProcedureCreate (procedureName=0x208bb0 "widget_in", returnsSet=0
> '\000',
> returnTypeName=0x208b30 "widget", languageName=0xefffcec8 "C",
> prosrc=0x18d7f8 "-",
> probin=0x251b10 "/usr/local/pgsql/src/test/regress/input/../regress.so",
> canCache=24 '\030',
> trusted=1 '\001', byte_pct=100, perbyte_cpu=0, percall_cpu=0,
> outin_ratio=100, argList=0x208b50,
> dest=Remote) at pg_proc.c:275
> #4 0x786c8 in CreateFunction (stmt=0x207650, dest=Remote) at define.c:329
> #5 0x131694 in ProcessUtility (parsetree=0x207650, dest=Remote) at
> utility.c:392
> #6 0x12db18 in pg_exec_query_dest (
> query_string=0xefffd130 " CREATE FUNCTION widget_in(opaque)\n RETURNS
> widget\n AS '/usr/local/pgsql/src/test/regress/input/../regress.so'\n
> LANGUAGE 'c';", dest=Remote, aclOverride=0 '\000') at postgres.c:720
> #7 0x12d98c in pg_exec_query (
> query_string=0xefffd130 " CREATE FUNCTION widget_in(opaque)\n RETURNS
> widget\n AS '/usr/local/pgsql/src/test/regress/input/../regress.so'\n
> LANGUAGE 'c';") at postgres.c:658
> #8 0x12f81c in PostgresMain (argc=9, argv=0xeffff210, real_argc=10,
> real_argv=0xeffffd84) at postgres.c:1578
> #9 0x10183c in DoBackend (port=0x209000) at postmaster.c:1519
> #10 0x100ffc in BackendStartup (port=0x209000) at postmaster.c:1291
> #11 0xffed8 in ServerLoop () at postmaster.c:750
> #12 0xff860 in PostmasterMain (argc=10, argv=0xeffffd84) at postmaster.c:556
> #13 0xb02c0 in main (argc=10, argv=0xeffffd84) at main.c:93
> (gdb)
>
> Has anyone else seen anything similar?
>
> Keith.
>
> PS: Bruce, I still need to find which file breaks an -O2 compile but
> will spend some time playing over this long weekend.
>
>
>