The following bug has been logged online:
Bug reference: 5566
Logged by: Hans van Kranenburg
Email address: hans.van.kranenburg@mendix.com
PostgreSQL version: 8.3.11
Operating system: Debian GNU/Linux 5.0
Description: High levels of savepoint nesting trigger stack overflow
in AssignTransactionId
Details:
Version: PostgreSQL 8.3.11 on x86_64-pc-linux-gnu, compiled by GCC
gcc-4.3.real (Debian 4.3.2-1.1) 4.3.2
When issuing an update statement in a transaction with ~30800 levels of
savepoint nesting, (which is insane, but possible), postgresql segfaults due
to a stack overflow in the AssignTransactionId function, which recursively
assign transaction ids to parent transactions.
After noticing the segfaults, we tried to reproduce, dump core and got the
following stacktrace (name/IP address munged):
Core was generated by `postgres: dummy dummy 82.94.x.y(50442) UPDATE
'.
Program terminated with signal 11, Segmentation fault.
[New process 9454]
#0 0x0000000000483e5a in ?? ()
(gdb) bt
#0 0x0000000000483e5a in ?? ()
#1 0x0000000000483f4d in ?? ()
#2 0x0000000000483f4d in ?? ()
[...]
#30802 0x0000000000483f4d in ?? ()
#30803 0x0000000000483f4d in ?? ()
#30804 0x0000000000483f4d in ?? ()
#30805 0x0000000000483fa8 in GetCurrentTransactionId ()
#30806 0x000000000046ccc9 in heap_update ()
#30807 0x0000000000534a90 in ExecutorRun ()
#30808 0x00000000005d7ce2 in ?? ()
#30809 0x00000000005d7f38 in ?? ()
#30810 0x00000000005d883b in PortalRun ()
#30811 0x00000000005d54c1 in PostgresMain ()
#30812 0x00000000005a7098 in ?? ()
#30813 0x00000000005a7f60 in PostmasterMain ()
#30814 0x000000000055adae in main ()
This UPDATE statement triggered the AssignTransactionId function. In the
transaction, only SELECT statements were issued up to this point. The
creation of this amount of savepoints was a bug in non-postgresql software
that's using the database. Nonetheless a database user should not be able to
segfault the entire server process by behaving like this.
Greetings,
Hans van Kranenburg
