cstore_fdw icon indicating copy to clipboard operation
cstore_fdw copied to clipboard

segmentation fault after truncate

Open matteodurighetto opened this issue 8 years ago • 2 comments

Hello, in Centos 7.1 with postgres 9.5.3 with cstore 1.4.1 ( rpm from yum.postgresql.org ) sometime during the truncate of another type of table ( unlogged ) , it's possible that the backend got a segmentation fault. I am thinking to mody the ddl trigger ( cstore_ddl_event_end_trigger ) to not fire during truncate, by the way in the documentation ( https://www.postgresql.org/docs/9.5/static/sql-createeventtrigger.html ) the filter is base on a list of command , so I could not set "not in ( truncate table )". Any idea ? ` #0 0x00000000005eae17 in list_copy (oldlist=0x17267e8) at list.c:1179 #1 0x00007f2496158ca8 in CStoreProcessUtility () from /usr/pgsql-9.5/lib/cstore_fdw.so #2 0x00007f2495d44b6c in pgss_ProcessUtility (parsetree=0x17f1f50, queryString=0x17e38b8 "truncate table _._************",

context=PROCESS_UTILITY_QUERY, params=0x0, dest=0xbd1e00 <spi_printtupDR>, completionTag=0x7fffaaedd7e0 "") at pg_stat_statements.c:1053

#3 0x00000000005d47da in _SPI_execute_plan (plan=plan@entry=0x17f1af0, paramLI=paramLI@entry=0x0, snapshot=snapshot@entry=0x0,

crosscheck_snapshot=crosscheck_snapshot@entry=0x0, read_only=read_only@entry=0 '\000', fire_triggers=fire_triggers@entry=1 '\001',
tcount=tcount@entry=0) at spi.c:2200

#4 0x00000000005d4e98 in SPI_execute_plan_with_paramlist (plan=0x17f1af0, params=0x0, read_only=, tcount=0) at spi.c:450 #5 0x00007f24959204d7 in exec_stmt_execsql (estate=estate@entry=0x7fffaaedddf0, stmt=stmt@entry=0x16fb108) at pl_exec.c:3568 #6 0x00007f2495921c77 in exec_stmt (stmt=0x16fb108, estate=0x7fffaaedddf0) at pl_exec.c:1544 #7 exec_stmts (estate=0x7fffaaedddf0, stmts=) at pl_exec.c:1439 #8 0x00007f2495923959 in exec_stmt_block (estate=estate@entry=0x7fffaaedddf0, block=block@entry=0x17145c0) at pl_exec.c:1238 #9 0x00007f249592183f in exec_stmt (stmt=0x17145c0, estate=0x7fffaaedddf0) at pl_exec.c:1472 #10 exec_stmts (estate=0x7fffaaedddf0, stmts=) at pl_exec.c:1439 #11 0x00007f2495923ab8 in exec_stmt_block (estate=estate@entry=0x7fffaaedddf0, block=0x1714660) at pl_exec.c:1377 #12 0x00007f2495923ce1 in plpgsql_exec_function (func=func@entry=0x16b4968, fcinfo=fcinfo@entry=0x163b9a0, simple_eval_estate=simple_eval_estate@entry=0x0)

at pl_exec.c:426

#13 0x00007f2495918d17 in plpgsql_call_handler (fcinfo=0x163b9a0) at pl_handler.c:253 #14 0x00000000005b1be2 in ExecMakeFunctionResultNoSets (fcache=0x163b930, econtext=0x163b740, isNull=0x163c338 "@\333d\001", isDone=)

at execQual.c:2019

#15 0x00000000005b751d in ExecTargetList (isDone=0x7fffaaede104, itemIsDone=0x163c450, isnull=, values=0x163c320, econtext=0x163b740,

targetlist=0x163c420) at execQual.c:5365

#16 ExecProject (projInfo=, isDone=isDone@entry=0x7fffaaede104) at execQual.c:5580 #17 0x00000000005ca962 in ExecResult (node=node@entry=0x163b630) at nodeResult.c:155 #18 0x00000000005b0ad8 in ExecProcNode (node=node@entry=0x163b630) at execProcnode.c:385 #19 0x00000000005adc90 in ExecutePlan (dest=0x35308c0, direction=, numberTuples=0, sendTuples=1 '\001', operation=CMD_SELECT,

planstate=0x163b630, estate=0x163b520) at execMain.c:1549

#20 standard_ExecutorRun (queryDesc=0x18133f0, direction=, count=0) at execMain.c:337 #21 0x00007f2495d43065 in pgss_ExecutorRun (queryDesc=0x18133f0, direction=ForwardScanDirection, count=0) at pg_stat_statements.c:877 #22 0x00000000006ad278 in PortalRunSelect (portal=portal@entry=0x1632610, forward=forward@entry=1 '\001', count=0, count@entry=9223372036854775807,

dest=dest@entry=0x35308c0) at pquery.c:942

#23 0x00000000006ae67b in PortalRun (portal=0x1632610, count=9223372036854775807, isTopLevel=, dest=0x35308c0, altdest=0x35308c0,

completionTag=0x7fffaaede6a0 "") at pquery.c:786

#24 0x00000000006ac333 in PostgresMain (argc=, argv=, dbname=, username=) at postgres.c:1104 #25 0x0000000000469061 in BackendRun (port=0x1638780) at postmaster.c:4239 #26 BackendStartup (port=0x1638780) at postmaster.c:3913 #27 ServerLoop () at postmaster.c:1684 #28 0x0000000000655976 in PostmasterMain (argc=argc@entry=3, argv=argv@entry=0x16182d0) at postmaster.c:1292 #29 0x0000000000469c8e in main (argc=3, argv=0x16182d0) at main.c:228

another stack trace :

(gdb) bt #0 RangeVarGetRelidExtended (relation=relation@entry=0x259, lockmode=lockmode@entry=1, missing_ok=missing_ok@entry=1 '\001', nowait=nowait@entry=0 '\000',

callback=callback@entry=0x0, callback_arg=callback_arg@entry=0x0) at namespace.c:244

#1 0x00007fe4b56acc76 in FindCStoreTables (tableList=0x1b5ed78) at cstore_fdw.c:573 #2 CStoreProcessUtility (parseTree=0x1c08f10, queryString=0x1c2e528 "truncate table *_._***********i", context=PROCESS_UTILITY_QUERY,

paramListInfo=0x0, destReceiver=0xbd1e00 <spi_printtupDR>, completionTag=0x7ffe66d3b0a0 "") at cstore_fdw.c:258

#3 0x00000000005d47da in _SPI_execute_plan (plan=plan@entry=0x1c08ab0, paramLI=paramLI@entry=0x0, snapshot=snapshot@entry=0x0,

crosscheck_snapshot=crosscheck_snapshot@entry=0x0, read_only=read_only@entry=0 '\000', fire_triggers=fire_triggers@entry=1 '\001',
tcount=tcount@entry=0) at spi.c:2200

#4 0x00000000005d4e98 in SPI_execute_plan_with_paramlist (plan=0x1c08ab0, params=0x0, read_only=, tcount=0) at spi.c:450 #5 0x00007fe4f6c254d7 in exec_stmt_execsql (estate=estate@entry=0x7ffe66d3b6b0, stmt=stmt@entry=0x1b33698) at pl_exec.c:3568 #6 0x00007fe4f6c26c77 in exec_stmt (stmt=0x1b33698, estate=0x7ffe66d3b6b0) at pl_exec.c:1544 #7 exec_stmts (estate=0x7ffe66d3b6b0, stmts=) at pl_exec.c:1439 #8 0x00007fe4f6c28959 in exec_stmt_block (estate=estate@entry=0x7ffe66d3b6b0, block=block@entry=0x1b4cb50) at pl_exec.c:1238 #9 0x00007fe4f6c2683f in exec_stmt (stmt=0x1b4cb50, estate=0x7ffe66d3b6b0) at pl_exec.c:1472 #10 exec_stmts (estate=0x7ffe66d3b6b0, stmts=) at pl_exec.c:1439 #11 0x00007fe4f6c28ab8 in exec_stmt_block (estate=estate@entry=0x7ffe66d3b6b0, block=0x1b4cbf0) at pl_exec.c:1377 #12 0x00007fe4f6c28ce1 in plpgsql_exec_function (func=func@entry=0x1aee698, fcinfo=fcinfo@entry=0x1a749a0, simple_eval_estate=simple_eval_estate@entry=0x0)

at pl_exec.c:426

#13 0x00007fe4f6c1dd17 in plpgsql_call_handler (fcinfo=0x1a749a0) at pl_handler.c:253 #14 0x00000000005b1be2 in ExecMakeFunctionResultNoSets (fcache=0x1a74930, econtext=0x1a74740, isNull=0x1a75338 "", isDone=)

at execQual.c:2019

#15 0x00000000005b751d in ExecTargetList (isDone=0x7ffe66d3b9c4, itemIsDone=0x1a75450, isnull=, values=0x1a75320, econtext=0x1a74740,

targetlist=0x1a75420) at execQual.c:5365

#16 ExecProject (projInfo=, isDone=isDone@entry=0x7ffe66d3b9c4) at execQual.c:5580 #17 0x00000000005ca962 in ExecResult (node=node@entry=0x1a74630) at nodeResult.c:155 #18 0x00000000005b0ad8 in ExecProcNode (node=node@entry=0x1a74630) at execProcnode.c:385 #19 0x00000000005adc90 in ExecutePlan (dest=0x1e5a290, direction=, numberTuples=0, sendTuples=1 '\001', operation=CMD_SELECT,

planstate=0x1a74630, estate=0x1a74520) at execMain.c:1549

#20 standard_ExecutorRun (queryDesc=0x1d30760, direction=, count=0) at execMain.c:337 #21 0x00007fe4f7048065 in pgss_ExecutorRun (queryDesc=0x1d30760, direction=ForwardScanDirection, count=0) at pg_stat_statements.c:877 #22 0x00000000006ad278 in PortalRunSelect (portal=portal@entry=0x1a6b610, forward=forward@entry=1 '\001', count=0, count@entry=9223372036854775807,

dest=dest@entry=0x1e5a290) at pquery.c:942

#23 0x00000000006ae67b in PortalRun (portal=0x1a6b610, count=9223372036854775807, isTopLevel=, dest=0x1e5a290, altdest=0x1e5a290,

completionTag=0x7ffe66d3bf60 "") at pquery.c:786

#24 0x00000000006ac333 in PostgresMain (argc=, argv=, dbname=, username=) at postgres.c:1104 #25 0x0000000000469061 in BackendRun (port=0x1a71eb0) at postmaster.c:4239 #26 BackendStartup (port=0x1a71eb0) at postmaster.c:3913 #27 ServerLoop () at postmaster.c:1684 #28 0x0000000000655976 in PostmasterMain (argc=argc@entry=3, argv=argv@entry=0x1a512d0) at postmaster.c:1292 #29 0x0000000000469c8e in main (argc=3, argv=0x1a512d0) at main.c:228

`kind Regards

matteodurighetto avatar Jul 22 '16 06:07 matteodurighetto

Hi @matteodurighetto

Could you provide the steps leading to this crash ? That would help reproducing the issue at our end. thanks

mtuncer avatar Jul 22 '16 06:07 mtuncer

@matteodurighetto still I can't reproduce.

Tried at Centos 7.1 at AWS with Postgresql 9.5.3 installed from yum.postgresql.org and cstore_fdw v1.4.1 downloaded from github.

I also tried with pgbench to concurrently truncate logged/unlogged tables. Still could not get anything leading to this crash.

mtuncer avatar Jul 29 '16 11:07 mtuncer