Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Assertion IS_VALID_CHUNK(chunk) fails in CI run #4900

Closed
svenklemm opened this issue Oct 30, 2022 · 5 comments
Closed

Assertion IS_VALID_CHUNK(chunk) fails in CI run #4900

svenklemm opened this issue Oct 30, 2022 · 5 comments
Assignees
@svenklemm
Labels
bug

Comments

@svenklemm
Copy link
Member

For some reason chunk->relkind is 0

Link to failed run:
https://github.com/timescale/timescaledb/actions/runs/3352772875/jobs/5555143368

Stacktrace:

#2  0x0000555bd6e6cd73 in ExceptionalCondition (conditionName=conditionName@entry=0x7f2ec177fca0 "IS_VALID_CHUNK(chunk)", errorType=errorType@entry=0x7f2ec177ed20 "FailedAssertion",
    fileName=fileName@entry=0x7f2ec177ee20 "/home/runner/work/timescaledb/timescaledb/src/chunk.c", lineNumber=lineNumber@entry=2495) at assert.c:67
#3  0x00007f2ec15ab962 in chunk_scan_find (indexid=indexid@entry=2, scankey=scankey@entry=0x7ffeade367a0, nkeys=nkeys@entry=2, mctx=mctx@entry=0x625000109100, fail_if_not_found=fail_if_not_found@entry=true,
    displaykey=displaykey@entry=0x7f2ec1804220 <displaykey>) at /home/runner/work/timescaledb/timescaledb/src/chunk.c:2495
#4  0x00007f2ec15b66ab in ts_chunk_get_by_name_with_memory_context (schema_name=schema_name@entry=0x6250001092e0 "_timescaledb_internal", table_name=<optimized out>, mctx=<optimized out>, fail_if_not_found=fail_if_not_found@entry=true)
    at /home/runner/work/timescaledb/timescaledb/src/chunk.c:2546
#5  0x00007f2ec15b67d4 in ts_chunk_get_by_relid (relid=relid@entry=18748, fail_if_not_found=fail_if_not_found@entry=true) at /home/runner/work/timescaledb/timescaledb/src/chunk.c:2570
#6  0x00007f2ec0c1ed55 in tsl_compress_chunk (fcinfo=0x6250000f0958) at /home/runner/work/timescaledb/timescaledb/tsl/src/compression/api.c:575
#7  0x00007f2ec15e1fc9 in ts_compress_chunk (fcinfo=0x6250000f0958) at /home/runner/work/timescaledb/timescaledb/src/cross_module_fn.c:85
#8  0x0000555bd60975ab in ExecInterpExpr (state=0x6250000f0870, econtext=0x6250000f0570, isnull=0x7ffeade36a90) at execExprInterp.c:704
#9  0x0000555bd607f775 in ExecInterpExprStillValid (state=0x6250000f0870, econtext=0x6250000f0570, isNull=0x7ffeade36a90) at execExprInterp.c:1807
#10 0x0000555bd61f1b41 in ExecEvalExprSwitchContext (state=state@entry=0x6250000f0870, econtext=econtext@entry=0x6250000f0570, isNull=isNull@entry=0x7ffeade36a90) at ../../../src/include/executor/executor.h:322
#11 0x0000555bd61f1ce0 in ExecProject (projInfo=0x6250000f0868) at ../../../src/include/executor/executor.h:356
#12 0x0000555bd61f284a in ExecResult (pstate=<optimized out>) at nodeResult.c:136
#13 0x0000555bd60e55b4 in ExecProcNodeFirst (node=0x6250000f0458) at execProcnode.c:450
#14 0x0000555bd60b4b18 in ExecProcNode (node=node@entry=0x6250000f0458) at ../../../src/include/executor/executor.h:248
#15 0x0000555bd60b4d08 in ExecutePlan (estate=estate@entry=0x6250000f0220, planstate=0x6250000f0458, use_parallel_mode=<optimized out>, use_parallel_mode@entry=false, operation=operation@entry=CMD_SELECT,
    sendTuples=sendTuples@entry=true, numberTuples=numberTuples@entry=0, direction=ForwardScanDirection, dest=0x555bd74ea2e0 <spi_printtupDR>, execute_once=true) at execMain.c:1632
#16 0x0000555bd60b986b in standard_ExecutorRun (queryDesc=0x62500009f7e0, direction=ForwardScanDirection, count=0, execute_once=execute_once@entry=true) at execMain.c:350
#17 0x0000555bd60b9d82 in ExecutorRun (queryDesc=queryDesc@entry=0x62500009f7e0, direction=direction@entry=ForwardScanDirection, count=count@entry=0, execute_once=execute_once@entry=true) at execMain.c:294
#18 0x0000555bd62401c4 in _SPI_pquery (queryDesc=queryDesc@entry=0x62500009f7e0, fire_triggers=fire_triggers@entry=true, tcount=tcount@entry=0) at spi.c:2639
#19 0x0000555bd6249c93 in _SPI_execute_plan (plan=plan@entry=0x619000084ea0, paramLI=paramLI@entry=0x625000100998, snapshot=snapshot@entry=0x0, crosscheck_snapshot=crosscheck_snapshot@entry=0x0, read_only=read_only@entry=false,
    fire_triggers=fire_triggers@entry=true, tcount=<optimized out>) at spi.c:2418
#20 0x0000555bd624ba26 in SPI_execute_plan_with_paramlist (plan=0x619000084ea0, params=params@entry=0x625000100998, read_only=read_only@entry=false, tcount=tcount@entry=0) at spi.c:679
#21 0x00007f2ec0261614 in exec_run_select (estate=estate@entry=0x7ffeade37b60, expr=0x62d0000a0b80, maxtuples=maxtuples@entry=0, portalP=portalP@entry=0x0) at pl_exec.c:5967
#22 0x00007f2ec0262452 in exec_stmt_perform (estate=estate@entry=0x7ffeade37b60, stmt=stmt@entry=0x62d0000a0c70) at pl_exec.c:2129
#23 0x00007f2ec027e413 in exec_stmt (estate=estate@entry=0x7ffeade37b60, stmt=0x62d0000a0c70) at pl_exec.c:1985
#24 0x00007f2ec0280d8a in exec_stmts (estate=estate@entry=0x7ffeade37b60, stmts=0x62d0000a0ca8) at pl_exec.c:1944
#25 0x00007f2ec0281a98 in exec_stmt_block (estate=estate@entry=0x7ffeade37b60, block=block@entry=0x62d0000a1a98) at pl_exec.c:1736
#26 0x00007f2ec027e2d4 in exec_stmt (estate=estate@entry=0x7ffeade37b60, stmt=0x62d0000a1a98) at pl_exec.c:1977
#27 0x00007f2ec0280d8a in exec_stmts (estate=estate@entry=0x7ffeade37b60, stmts=0x62d0000a1af0) at pl_exec.c:1944
#28 0x00007f2ec02836ac in exec_stmt_if (estate=estate@entry=0x7ffeade37b60, stmt=stmt@entry=0x62d0000a3ef0) at pl_exec.c:2522
#29 0x00007f2ec027e44c in exec_stmt (estate=estate@entry=0x7ffeade37b60, stmt=0x62d0000a3ef0) at pl_exec.c:1997
#30 0x00007f2ec0280d8a in exec_stmts (estate=estate@entry=0x7ffeade37b60, stmts=0x62d0000a3f48) at pl_exec.c:1944
#31 0x00007f2ec0286f17 in exec_for_query (estate=estate@entry=0x7ffeade37b60, stmt=stmt@entry=0x62d0000a0640, portal=0x62500008c338, prefetch_ok=<optimized out>, prefetch_ok@entry=true) at pl_exec.c:6107
#32 0x00007f2ec02875d3 in exec_stmt_fors (estate=estate@entry=0x7ffeade37b60, stmt=stmt@entry=0x62d0000a0640) at pl_exec.c:2839
#33 0x00007f2ec027e4ab in exec_stmt (estate=estate@entry=0x7ffeade37b60, stmt=0x62d0000a0640) at pl_exec.c:2017
#34 0x00007f2ec0280d8a in exec_stmts (estate=estate@entry=0x7ffeade37b60, stmts=0x6290000ca448) at pl_exec.c:1944
#35 0x00007f2ec0283053 in exec_stmt_block (estate=estate@entry=0x7ffeade37b60, block=block@entry=0x62d0000a4ea0) at pl_exec.c:1885
#36 0x00007f2ec027e2d4 in exec_stmt (estate=estate@entry=0x7ffeade37b60, stmt=stmt@entry=0x62d0000a4ea0) at pl_exec.c:1977
#37 0x00007f2ec027f83f in plpgsql_exec_function (func=func@entry=0x62d000083040, fcinfo=fcinfo@entry=0x7ffeade38070, simple_eval_estate=simple_eval_estate@entry=0x0, simple_eval_resowner=simple_eval_resowner@entry=0x0,
    atomic=<optimized out>) at pl_exec.c:611
#38 0x00007f2ec02baa6a in plpgsql_call_handler (fcinfo=<optimized out>) at pl_handler.c:265
#39 0x0000555bd5eed631 in ExecuteCallStmt (stmt=<optimized out>, params=params@entry=0x6250000ba888, atomic=atomic@entry=false, dest=dest@entry=0x555bd74ea2e0 <spi_printtupDR>) at functioncmds.c:2249
#40 0x0000555bd6944777 in standard_ProcessUtility (pstmt=pstmt@entry=0x61900006fc10,
    queryString=queryString@entry=0x61d000027a68 "CALL _timescaledb_internal.policy_compression_execute(\n        job_id, htid, lag_value::INTERVAL,\n        maxchunks, verbose_log, recompress_enabled\n      )",
    context=context@entry=PROCESS_UTILITY_QUERY_NONATOMIC, params=params@entry=0x6250000ba888, queryEnv=queryEnv@entry=0x0, dest=dest@entry=0x555bd74ea2e0 <spi_printtupDR>, qc=<optimized out>) at utility.c:834
#41 0x00007f2ecb4748a5 in loader_process_utility_hook (pstmt=0x61900006fc10, query_string=<optimized out>, context=<optimized out>, params=<optimized out>, queryEnv=<optimized out>, dest=<optimized out>, completion_tag=<optimized out>)
    at /home/runner/work/timescaledb/timescaledb/src/loader/loader.c:582
@svenklemm svenklemm added the bug label Oct 30, 2022
@konskov konskov mentioned this issue Nov 2, 2022
Closed
@jnidzwetzki
Copy link
Contributor

Still happening: https://github.com/timescale/timescaledb/actions/runs/3623943605/jobs/6110377224

@jnidzwetzki jnidzwetzki added this to the TimescaleDB 2.9 milestone Dec 8, 2022
@SachinSetiya SachinSetiya self-assigned this Dec 9, 2022
mkindahl added a commit to mkindahl/timescaledb that referenced this issue Dec 9, 2022
@mkindahl
Set cache pointer to null before destroying
b079227 
A cache is used for the duration of a query to speed up planning time,
but when destroying the cache, an error in the destruction would leave
the cache pointer pointing to a partially or fully destroyed cache,
which would give incorrect cache hits for the next query.

This commit changes the order of the assignment so that the cache
pointer is cleared before destroying the cache. This will allocate a
new cache for the next query, even if the previous destruction had an
error.

Fixes timescale#4900
@mkindahl mkindahl mentioned this issue Dec 9, 2022
Closed
mkindahl added a commit to mkindahl/timescaledb that referenced this issue Dec 9, 2022
@mkindahl
Set cache pointer to null before destroying
9eb3458 
A cache is used for the duration of a query to speed up planning time,
but when destroying the cache, an error in the destruction would leave
the cache pointer pointing to a partially or fully destroyed cache,
which would give incorrect cache hits for the next query.

This commit changes the order of the assignment so that the cache
pointer is cleared before destroying the cache. This will allocate a
new cache for the next query, even if the previous destruction had an
error.

Fixes timescale#4900
@SachinSetiya SachinSetiya assigned mkindahl and unassigned SachinSetiya Dec 9, 2022
@mkindahl mkindahl removed their assignment Dec 9, 2022
@jnidzwetzki jnidzwetzki mentioned this issue Dec 12, 2022
Closed
@iroussos
Copy link

@jnidzwetzki is #5074 a fix for this?

@SachinSetiya
Copy link
Contributor

SachinSetiya commented Dec 12, 2022 •
edited

I dont think #5074 is a fix for it, #4900 still occurs in #5074 CI runs

@jnidzwetzki
Copy link
Contributor

It was a test PR to trigger Sanitizer CI runs. I had a theory about #4795 that I was trying to verify. I closed my PR because @mkindahl has a much more reasonable theory about #4795.

This issue (#4900) seems to be something completely different.

@jfjoly jfjoly removed this from the TimescaleDB 2.9 milestone Dec 16, 2022
@fabriziomello
Copy link
Contributor

Seems #5086 fixes it. Closing!

@svenklemm svenklemm mentioned this issue Mar 11, 2023
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@svenklemm svenklemm

Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@fabriziomello @mkindahl @jnidzwetzki @SachinSetiya @jfjoly @iroussos @svenklemm