BUG #5235: Segmentation fault under high load through JDBC

The following bug has been logged online:

Bug reference: 5235
Logged by: Oleg Yurchenko
Email address: oleg(at)fts(dot)ee
PostgreSQL version: 8.4.1
Operating system: FreeBSD 8.0-RELEASE #0 Generic kernel i386
Description: Segmentation fault under high load through JDBC
Details:

Postgres-8.4.1 back-end crashes with segmentation fault after 20-30 min of
high load through postgres-jdbc. Tried different versions of jdbc:
postgresql-8.4-701.jdbc3.jar, postgresql-8.3-605.jdbc3.jar,
postgresql-jdbc-8.3.603_1

Core dump and bt are following:

# gdb -c /usr/local/pgsql/data/postgres.core postgres
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
Core was generated by `postgres'.
Program terminated with signal 11, Segmentation fault.
#0 0x0839380b in MemoryContextAllocZeroAligned (context=0x2d9eaf70,
size=16) at mcxt.c:559
559 mcxt.c: No such file or directory.
in mcxt.c
[New Thread 28b01140 (LWP 100115)]

#(gdb)bt
#14185 0x081c1024 in ExecTargetList (targetlist=0x2b61a158,
econtext=0x2b619330, values=0x2b61a0c8, isnull=0x2b61a0d8 "",
itemIsDone=0x2b61a170, isDone=0xbfbfe4f0) at execQual.c:5007
#14186 0x081c14cd in ExecProject (projInfo=0x2b61a0e8, isDone=0xbfbfe4f0) at
execQual.c:5222
#14187 0x081c1623 in ExecScan (node=0x2b6192a8, accessMtd=0x81d5120
<SubqueryNext>) at execScan.c:143
#14188 0x081d516a in ExecSubqueryScan (node=0x2b6192a8) at
nodeSubqueryscan.c:85
#14189 0x081b7f9e in ExecProcNode (node=0x2b6192a8) at execProcnode.c:381
#14190 0x081b598e in ExecutePlan (estate=0x2b619018, planstate=0x2b6192a8,
operation=CMD_SELECT, numberTuples=0,
---Type <return> to continue, or q <return> to quit---
direction=ForwardScanDirection, dest=0x28bc4420) at execMain.c:1504
#14191 0x081b3d53 in standard_ExecutorRun (queryDesc=0x2b789e40,
direction=ForwardScanDirection, count=0) at execMain.c:309
#14192 0x081b3c66 in ExecutorRun (queryDesc=0x2b789e40,
direction=ForwardScanDirection, count=0) at execMain.c:258
#14193 0x082958a7 in PortalRunSelect (portal=0x2ab68018, forward=1 '\001',
count=0, dest=0x28bc4420) at pquery.c:953
#14194 0x082955c0 in PortalRun (portal=0x2ab68018, count=2147483647,
isTopLevel=1 '\001', dest=0x28bc4420,
altdest=0x28bc4420, completionTag=0xbfbfe7d4 "") at pquery.c:779
#14195 0x0829155f in exec_execute_message (portal_name=0x28bc4018 "",
max_rows=2147483647) at postgres.c:1928
#14196 0x08293e23 in PostgresMain (argc=4, argv=0x28b3b890,
username=0x28b3b7c0 "tad") at postgres.c:3671
#14197 0x0825e2d0 in BackendRun (port=0x28b2f600) at postmaster.c:3447
#14198 0x0825d7b3 in BackendStartup (port=0x28b2f600) at postmaster.c:3061
#14199 0x0825ad4a in ServerLoop () at postmaster.c:1387
#14200 0x0825a466 in PostmasterMain (argc=3, argv=0xbfbfec2c) at
postmaster.c:1040
#14201 0x081ea4e5 in main (argc=3, argv=0xbfbfec2c) at main.c:188

Regards,

Oleg