server crash on query

[desoi]

Hi,

Setup: OS X 10.6.8; ODBC database is 4th Dimension (4D) 12.3.

I setup a simple example with 1 field based on the example found in the readme file. I have verified the connection works using a different application. When I try to run a simple select query, postgres crashes (log below). I have also included a crash backtrace. 4D is not a 64 bit application. Could this be the problem?

LOG: server process (PID 19335) was terminated by signal 11: Segmentation fault
LOG: terminating any other active server processes
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and repeat your command.
LOG: all server processes terminated; reinitializing

Process: postgres [19335]
Path: /sw/postgresql-9.1.1/bin/postgres
Identifier: postgres
Version: ??? (???)
Code Type: X86-64 (Native)
Parent Process: postgres [16402]

Date/Time: 2011-12-04 10:16:23.747 -0500
OS Version: Mac OS X 10.6.8 (10K549)
Report Version: 6

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000538
Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 odbc_fdw.so 0x00000001007701a8 SQLAllocStmt_Internal + 49
1 odbc_fdw.so 0x000000010077e108 SQLAllocHandle_Internal + 234
2 odbc_fdw.so 0x000000010077e47b SQLAllocHandle + 208
3 odbc_fdw.so 0x00000001007619f5 odbcGetTableSize + 277
4 odbc_fdw.so 0x0000000100761dcb odbcPlanForeignScan + 251
5 postgres 0x000000010019ea08 create_foreignscan_path + 120
6 postgres 0x0000000100176e84 set_rel_pathlist + 3844
7 postgres 0x000000010017716b make_one_rel + 107
8 postgres 0x000000010018cae4 query_planner + 548
9 postgres 0x000000010018e41d grouping_planner + 3117
10 postgres 0x00000001001901fd subquery_planner + 2125
11 postgres 0x0000000100190559 standard_planner + 233
12 postgres 0x00000001001f0809 pg_plan_query + 73
13 postgres 0x00000001001f08dc pg_plan_queries + 92
14 postgres 0x00000001001f1e11 exec_simple_query + 369
15 postgres 0x00000001001f2b11 PostgresMain + 2049
16 postgres 0x00000001001b1eb8 ServerLoop + 2792
17 postgres 0x00000001001b2d62 PostmasterMain + 2658
18 postgres 0x000000010014f275 main + 933
19 postgres 0x0000000100001384 start + 52

Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000000 rbx: 0x0000000100602640 rcx: 0x00007fff70c57650 rdx: 0x00000000000fc080
rdi: 0x0000000100602640 rsi: 0x00007fff5fbfd4c8 rbp: 0x00007fff5fbfd370 rsp: 0x00007fff5fbfd310
r8: 0x0000000000000000 r9: 0x00000001006024e0 r10: 0x0000000000000000 r11: 0x0000000000000004
r12: 0x0000000100602640 r13: 0x00007fff5fbfd4c8 r14: 0x0000000100602640 r15: 0x00000001007a0820
rip: 0x00000001007701a8 rfl: 0x0000000000010202 cr2: 0x0000000000000538

Binary Images:
0x100000000 - 0x100484fff +postgres ??? (???) <6C557CC4-B14F-B825-2E80-BE9BF5FB1EA3> /sw/postgresql-9.1.1/bin/postgres
0x100760000 - 0x10079dfff +odbc_fdw.so ??? (???) <80E894DF-A8ED-B9F7-E981-D09BD0E0F5EC> /sw/postgresql-test/lib/odbc_fdw.so
0x7fff5fc00000 - 0x7fff5fc3bdef dyld 132.1 (???) <486E6C61-1197-CC7C-2197-82CE505102D7> /usr/lib/dyld
0x7fff85b01000 - 0x7fff85b05ff7 libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) <95718673-FEEE-B6ED-B127-BCDBDB60D4E5> /usr/lib/system/libmathCommon.A.dylib
0x7fff868b8000 - 0x7fff86a79fef libSystem.B.dylib 125.2.11 (compatibility 1.0.0) <9AB4F1D1-89DC-0E8A-DC8E-A4FE4D69DB69> /usr/lib/libSystem.B.dylib
0x7fffffe00000 - 0x7fffffe01fff libSystem.B.dylib ??? (???) <9AB4F1D1-89DC-0E8A-DC8E-A4FE4D69DB69> /usr/lib/libSystem.B.dylib

[cinnion]

I am not so certain that we do not have a bigger problem with odbc_fdw on 64-bit systems. I have a several CentOS 5.8 system with Postgres 9.1, with odbc_fdw connecting to a MSSQL 2008R2 server for testing purposes. I have odbc_fdw running apparently fine on a 32-bit system development server, and recompiled everything from the matching source RPMs with debugging enabled on a second system. so that I could understand the FDW API better. However, the same exact query on a 64-bit system gets a SEGV with the following stack:

Program received signal SIGSEGV, Segmentation fault.
0x0825e22c in list_copy (oldlist=0x936674c) at list.c:1150
1150 newlist->head->data = oldlist->head->data;
(gdb) bt
#0 0x0825e22c in list_copy (oldlist=0x936674c) at list.c:1150
#1 0x0052fcd6 in odbcIterateForeignScan (node=0x9316624) at odbc_fdw.c:1123
#2 0x0823956a in ForeignNext (node=0x9316624) at nodeForeignscan.c:49
#3 0x0821e59b in ExecScanFetch (node=0x9316624, accessMtd=0x8239530 , recheckMtd=0x82395d1 ) at execScan.c:82
#4 0x0821e38e in ExecScan (node=0x9316624, accessMtd=0x8239530 , recheckMtd=0x82395d1 ) at execScan.c:167
#5 0x082395fe in ExecForeignScan (node=0x9316624) at nodeForeignscan.c:90
#6 0x082144c3 in ExecProcNode (node=0x9316624) at execProcnode.c:432
#7 0x082121df in ExecutePlan (estate=0x931654c, planstate=0x9316624, operation=CMD_SELECT, sendTuples=1 '\001', numberTuples=0, direction=ForwardScanDirection, dest=0x92fed4c) at execMain.c:1440
#8 0x08210810 in standard_ExecutorRun (queryDesc=0x9316144, direction=ForwardScanDirection, count=0) at execMain.c:314
#9 0x0821067c in ExecutorRun (queryDesc=0x9316144, direction=ForwardScanDirection, count=0) at execMain.c:262
#10 0x08336a51 in PortalRunSelect (portal=0x931b3ec, forward=1 '\001', count=0, dest=0x92fed4c) at pquery.c:943
#11 0x08336730 in PortalRun (portal=0x931b3ec, count=2147483647, isTopLevel=1 '\001', dest=0x92fed4c, altdest=0x92fed4c, completionTag=0xbfe5e306 "") at pquery.c:787
#12 0x08330a4b in exec_simple_query (query_string=0x92d266c "SELECT * FROM fdw."t_Stocks" WHERE "Ticker"='LMT';") at postgres.c:1020
#13 0x08334cd8 in PostgresMain (argc=2, argv=0x92597c8, username=0x92596b4 "nixbase") at postgres.c:3968
#14 0x082de4ed in BackendRun (port=0x927a858) at postmaster.c:3617
#15 0x082ddb06 in BackendStartup (port=0x927a858) at postmaster.c:3302
#16 0x082da92d in ServerLoop () at postmaster.c:1466
#17 0x082da05a in PostmasterMain (argc=3, argv=0x9258ba8) at postmaster.c:1127
#18 0x082556c7 in main (argc=3, argv=0x9258ba8) at main.c:199

The second system is almost exactly the same outside of the 32-bit vs. 64-bit. Both systems were built using the same, exact Kickstart file, so all the OS packages loaded by the install, and all the configuration files are the same beyond the 32/64-bit difference. The PostgreSQL server on the 64-bit machine was rebuilt with full debugging from the source RPMs matching the binary RPMs installed on the 32-bit machine, and the database on the 32-bit system was dumped and reloaded onto the 64-bit machine. And outside of two lines in odbc_fdw.c which have to be fixed to compile and work with debugging under 64-bit. there are no other differences. And the test database on the MSSQL side is just a set of tables giving stock exchanges and stocks in 3NF.

Of course, given other indications such as the fact that this issue was opened a year ago and there has been no change in either the bug or the code, and the fact that 9.2 has been out for 4 months, but nothing has been done to odbc_fdw so that it will work with 9.2, and lastly, that a query as simple as that in frame 12 results in a full scan of the the foreign tables (e.g. no query push-down, which was what I was fully wanting to understand) ... I think the 64-bit issue(s) might be one of our least worries right now.