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. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
