search

ZhengYang / odbc_fdw

PostgreSQL Foreign-data Wrapper for ODBC
Other
26 stars 45 forks source link

server crash on query #1

Open desoi opened 12 years ago

desoi commented 12 years ago

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 commented 11 years ago

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.