bug or simply not enough stack space? - Mailing list pgsql-bugs

From Frank van Vugt
Subject bug or simply not enough stack space?
Date
Msg-id 200907161545.20338.ftm.van.vugt@foxi.nl
Whole thread Raw
Responses Re: bug or simply not enough stack space?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
L.S.

We're working on some conversion script which in itself ran fine. We then
added a couple of additional checks, one of which was wrong and thus bailed
out, but ran into the following (from the log):


LOG: statement: update stock_item_composition set ......

ERROR: new row for relation "site_stock" violates check constraint

CONTEXT: SQL statement "............"

 PL/pgSQL function "tr_site_stock_amounts_after_iud" line 74 at SQL statement
 SQL statement "............"

 PL/pgSQL function "tr_stock_item_composition_after_iud" line 202 at SQL
statement

STATEMENT: update stock_item_composition set .........

ERROR: tupdesc reference 0x7ffe74eaf028 is not owned by resource owner
SubTransaction

WARNING: AbortSubTransaction while in ABORT state

WARNING: did not find subXID 75610 in MyProc

ERROR: tupdesc reference 0x7ffe74eaf028 is not owned by resource owner
SubTransaction

WARNING: AbortSubTransaction while in ABORT state

WARNING: did not find subXID 75610 in MyProc

ERROR: tupdesc reference 0x7ffe74eaf028 is not owned by resource owner
SubTransaction

WARNING: AbortSubTransaction while in ABORT state

WARNING: did not find subXID 75610 in MyProc

ERROR: tupdesc reference 0x7ffe74eaf028 is not owned by resource owner
SubTransaction

PANIC: ERRORDATA_STACK_SIZE exceeded

LOG: server process (PID 14757) was terminated by signal 6: Aborted



The backtrace itself is not very informative, if needed we can easily create a
new one based on breakpoint information provided:

(gdb) bt
#0 0x00007ffe7a7a7f05 in raise () from /lib64/libc.so.6
#1 0x00007ffe7a7a9960 in abort () from /lib64/libc.so.6
#2 0x0000000000675e05 in errfinish ()
#3 0x000000000067693f in elog_start ()
#4 0x000000000047518d in AbortSubTransaction ()
#5 0x0000000000475659 in AbortCurrentTransaction ()
#6 0x00000000005cf685 in PostgresMain ()
#7 0x00000000005a5155 in ServerLoop ()
#8 0x00000000005a5c9f in PostmasterMain ()
#9 0x0000000000554a70 in main ()



This is a 64-bit machine with 10GB mem, configured with max_stack_depth = 6MB,
the queries/checks/etc used are not recursive, so I found the above a bit
suspicious.





--
Best,




Frank.

pgsql-bugs by date:

Previous
From: Robert Haas
Date:
Subject: Re: Installation problems
Next
From: Tom Lane
Date:
Subject: Re: bug or simply not enough stack space?