bug or simply not enough stack space?

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.