PG 7.2.1 core dump

PG 7.2.1 core dump

Post by Tom Jenki » Fri, 16 Aug 2002 05:14:13



Hey folks,
While testing out a function that does updates on one of our databases,
i got a sig 11.  the same script ran fine on another machine, so it may
be hardware related.  oh wait, this is the script that changed to a
function; i believe i ran it as a script on the other machine - so it
may not be hardware related.

                            version
---------------------------------------------------------------
 PostgreSQL 7.2.1 on i686-pc-linux-gnu, compiled by GCC 2.95.4
(1 row)

Debian stable (3.0)

Loaded symbols for /usr/lib/postgresql-debug/lib/plpgsql.so
#0  0x080cf140 in _SPI_end_call (procmem=1) at spi.c:1355
1355            _SPI_current->qtlist = NULL;
(gdb) bt
#0  0x080cf140 in _SPI_end_call (procmem=1) at spi.c:1355
#1  0x080cd8fd in SPI_execp (plan=0x846e1f0, Values=0x836f8a0,
Nulls=0x836f888 "", tcount=0) at spi.c:234
#2  0x2ae4cee3 in exec_stmt_execsql (estate=0x7fffece0, stmt=0x837aa10)
at pl_exec.c:1915
#3  0x2ae4bc7a in exec_stmt (estate=0x7fffece0, stmt=0x837aa10) at
pl_exec.c:920
#4  0x2ae4baf5 in exec_stmts (estate=0x7fffece0, stmts=0x8379c10) at
pl_exec.c:846
#5  0x2ae4ba4f in exec_stmt_block (estate=0x7fffece0, block=0x837c148)
at pl_exec.c:802
#6  0x2ae4b03f in plpgsql_exec_function (func=0x8379638,
fcinfo=0x7fffed90) at pl_exec.c:324
#7  0x2ae48f0d in plpgsql_call_handler (fcinfo=0x7fffed90) at
pl_handler.c:140
#8  0x080c493d in ExecMakeFunctionResult (fcache=0x8356ac0,
arguments=0x0, econtext=0x83567e0, isNull=0x7fffeeaf "",
isDone=0x7fffeeb0) at execQual.c:825
#9  0x080c49fa in ExecEvalFunc (funcClause=0x83565c0,
econtext=0x83567e0, isNull=0x7fffeeaf "", isDone=0x7fffeeb0) at
execQual.c:919
#10 0x080c4f30 in ExecEvalExpr (expression=0x83565c0,
econtext=0x83567e0, isNull=0x7fffeeaf "", isDone=0x7fffeeb0) at
execQual.c:1364
#11 0x080c5209 in ExecTargetList (targetlist=0x8356638, nodomains=1,
targettype=0x8356828, values=0x8356950, econtext=0x83567e0,
isDone=0x7ffff09c) at execQual.c:1697
#12 0x080c549b in ExecProject (projInfo=0x8356650, isDone=0x7ffff09c) at
execQual.c:1921
#13 0x080cac93 in ExecResult (node=0x83566a0) at nodeResult.c:160
#14 0x080c3999 in ExecProcNode (node=0x83566a0, parent=0x0) at
execProcnode.c:274
#15 0x080c297e in ExecutePlan (estate=0x8356740, plan=0x83566a0,
operation=CMD_SELECT, numberTuples=0, direction=ForwardScanDirection,
destfunc=0x8356678)
    at execMain.c:976
#16 0x080c2017 in ExecutorRun (queryDesc=0x8356728, estate=0x8356740,
feature=3, count=0) at execMain.c:233
#17 0x0810f0be in ProcessQuery (parsetree=0x8354878, plan=0x83566a0,
dest=Remote, completionTag=0x7ffff200 "") at pquery.c:259
#18 0x0810d960 in pg_exec_query_string (query_string=0x8354570 "select
migrateopm();", dest=Remote, parse_context=0x832ab60) at postgres.c:811
#19 0x0810e93e in PostgresMain (argc=4, argv=0x7ffff430,
username=0x83263c9 "tjenkins") at postgres.c:1926
#20 0x080f5aae in DoBackend (port=0x8326298) at postmaster.c:2243
#21 0x080f53ff in BackendStartup (port=0x8326298) at postmaster.c:1874
#22 0x080f461c in ServerLoop () at postmaster.c:977
#23 0x080f419b in PostmasterMain (argc=1, argv=0x830f030) at
postmaster.c:771
#24 0x080d3c85 in main (argc=1, argv=0x7ffffdb4) at main.c:206
(gdb)
--

Tom Jenkins
Development InfoStructure
http://www.devis.com

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

 
 
 

PG 7.2.1 core dump

Post by Tom Jenki » Fri, 16 Aug 2002 05:21:03



> Hey folks,
> While testing out a function that does updates on one of our databases,
> i got a sig 11.  the same script ran fine on another machine, so it may
> be hardware related.  oh wait, this is the script that changed to a
> function; i believe i ran it as a script on the other machine - so it
> may not be hardware related.

This triggered a thought.  The script had ANALYZE statements.  they were
not removed when converted to a function.  i removed these ANALYZE
statements and the function ran.

So looks like in pl/pgsql if you have ANALYZE statements you can
(possibly) crash the server.

--

Tom Jenkins
Development InfoStructure
http://www.devis.com

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

 
 
 

PG 7.2.1 core dump

Post by Tom La » Fri, 16 Aug 2002 07:01:01



> So looks like in pl/pgsql if you have ANALYZE statements you can
> (possibly) crash the server.

Ah.  This is a variant of the "can't do VACUUM in a function" problem.
There's a test to prevent that in CVS tip...

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

 
 
 

1. Core dump on PG 7.1.3

Thanks ... I'll do that in the wee hours of tomorrow morning and let you
know how it turns out ...

Thanks for the quick responses ...

-Dave

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command

2. Q: BLOBS in OpenIngres1.1

3. Building perl mods pg:PG or DBD:PG on non-PostgreSQLable machines

4. CA-PALO ALTO-257859--ORACLE-C-C++-Client/Server-GUI-HTTP-Internet-JAVA SERVER-SIDE ENGINEERS FOR INTERNET COMPANY

5. Building perl mods pg:PG or DBD:PG on non

6. Report Printing

7. Fix for psql core dumping on bad user

8. Oracle JDBC Driver Setup

9. beta6 pg_restore core dumps

10. pfree() core dump in 7.2.3

11. HeapTuple header changes cause core dumps in CVS tip

12. JDBC core dumping

13. Troubleshooting cored dumps