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.

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

[YSQL] Occasional SIGSEGV in yb_cost_index #18689

Closed
1 task done
gauravk-in opened this issue Aug 15, 2023 · 0 comments
Closed
1 task done

[YSQL] Occasional SIGSEGV in yb_cost_index #18689

gauravk-in opened this issue Aug 15, 2023 · 0 comments
Assignees
Labels
area/ysql Yugabyte SQL (YSQL) kind/enhancement This is an enhancement of an existing feature priority/medium Medium priority issue status/awaiting-triage Issue awaiting triage

Comments

@gauravk-in
Copy link
Contributor

gauravk-in commented Aug 15, 2023

Jira Link: DB-7600

Description

Following query with more than one inequality filter on more than one index keys can lead to a very occasional SIGSEGV.

This only occurs when the new base scans cost model is enabled.

SET yb_enable_base_scans_cost_model = ON;
SET yb_enable_optimizer_statistics = ON;
create table test (k1 int, k2 int, k3 int, PRIMARY KEY (k1 ASC, k2 ASC, k3 ASC));
ANALYZE test;
/*+ IndexScan(test) */ explain select * from test where k1 > 10 and k1 < 20 and k2 > 10 and k2 < 30;

Here is the backtrace from the coredump.

* thread #1, name = 'postgres', stop reason = signal SIGSEGV
  * frame #0: 0x000055b42e04cdb4 postgres`list_nth_cell(list=0x0000000000000000, n=-2) at list.c:396:17
    frame #1: 0x000055b42e08e945 postgres`yb_cost_index(path=0x0000258abf17f570, root=0x0000258abf9c04b0, loop_count=1, partial_path=<unavailable>) at costsize.c:6337:14
    frame #2: 0x000055b42e0c8d34 postgres`create_index_path(root=0x0000258abf9c04b0, index=0x0000258abf9c1e58, indexclauses=0x0000258abf17f3e8, indexclausecols=0x0000258abf17f438, indexorderbys=0x0000000000000000, indexorderbycols=0x0000000000000000, pathkeys=0x0000000000000000, indexscandir=ForwardScanDirection, indexonly=<unavailable>, required_outer=0x0000000000000000, loop_count=0, partial_path=<unavailable>) at pathnode.c:1312:3
    frame #3: 0x000055b42e096375 postgres`build_index_paths(root=0x0000258abf9c04b0, rel=0x0000258abf9c1ab0, index=0x0000258abf9c1e58, clauses=0x00007ffe444453e8, useful_predicate=<unavailable>, scantype=ST_ANYSCAN, skip_nonnative_saop=0x00007ffe444453a7, skip_lower_saop=0x00007ffe444453a6) at indxpath.c:1332:11
    frame #4: 0x000055b42e093107 postgres`get_index_paths(root=<unavailable>, rel=<unavailable>, index=<unavailable>, clauses=<unavailable>, bitindexpaths=0x00007ffe44445728) at indxpath.c:959:15
    frame #5: 0x000055b42e092900 postgres`create_index_paths(root=0x0000258abf9c04b0, rel=0x0000258abf9c1ab0) at indxpath.c:281:3
    frame #6: 0x000055b42e022b3b postgres`ybcGetForeignPaths(root=0x0000258abf9c04b0, baserel=0x0000258abf9c1ab0, foreigntableid=<unavailable>) at ybc_fdw.c:177:2
    frame #7: 0x000055b42e086214 postgres`set_rel_pathlist(root=0x0000258abf9c04b0, rel=0x0000258abf9c1ab0, rti=1, rte=0x0000258abeb8db00) at allpaths.c:0
    frame #8: 0x000055b42e08305f postgres`make_one_rel at allpaths.c:360:3
    frame #9: 0x000055b42e083015 postgres`make_one_rel(root=0x0000258abf9c04b0, joinlist=0x0000258abf9c1e28) at allpaths.c:230:2
    frame #10: 0x000055b42e0ab905 postgres`query_planner(root=0x0000258abf9c04b0, tlist=0x0000258abf9c0f50, qp_callback=<unavailable>, qp_extra=0x00007ffe444459a8) at planmain.c:265:14
    frame #11: 0x000055b42e0ae923 postgres`grouping_planner(root=0x0000258abf9c04b0, inheritance_update=<unavailable>, tuple_fraction=<unavailable>) at planner.c:1928:17
    frame #12: 0x000055b42e0ace34 postgres`subquery_planner(glob=0x0000258abf9c0e00, parse=0x0000258abeb8d9f0, parent_root=0x0000000000000000, hasRecursion=false, tuple_fraction=0) at planner.c:976:3
    frame #13: 0x000055b42e0abc10 postgres`standard_planner(parse=0x0000258abeb8d9f0, cursorOptions=256, boundParams=<unavailable>) at planner.c:405:9
    frame #14: 0x00007ffab49cb053
    frame #15: 0x000055b42e1883f0 postgres`pg_plan_queries [inlined] pg_plan_query(querytree=<unavailable>, cursorOptions=<unavailable>, boundParams=0x0000000000000000) at postgres.c:893:9
    frame #16: 0x000055b42e1883b9 postgres`pg_plan_queries(querytrees=<unavailable>, cursorOptions=<unavailable>, boundParams=0x0000000000000000) at postgres.c:959:11
    frame #17: 0x000055b42e18f077 postgres`yb_exec_simple_query_impl at postgres.c:1136:19
    frame #18: 0x000055b42e18eb44 postgres`yb_exec_simple_query_impl(query_string=0x0000258abfd06118) at postgres.c:4748:2
    frame #19: 0x000055b42e18f7b9 postgres`yb_exec_query_wrapper_one_attempt(exec_context=0x0000258abfd06000, restart_data=0x00007ffe444461a0, functor=(postgres`yb_exec_simple_query_impl at postgres.c:4747), functor_context=0x0000258abfd06118, attempt=0, retry=0x00007ffe444463c8) at postgres.c:4716:3
    frame #20: 0x000055b42e18bb88 postgres`PostgresMain at postgres.c:4740:3
    frame #21: 0x000055b42e18bb54 postgres`PostgresMain [inlined] yb_exec_simple_query(query_string="/*+  SeqScan(t_range_1m_4keys) */ select * from t_range_1m_4keys where k1 > 2 and k1 < 8 and k2 > 5 and k2 < 10", exec_context=0x0000258abfd06000) at postgres.c:4763:2
    frame #22: 0x000055b42e18bb4d postgres`PostgresMain(argc=<unavailable>, argv=0x0000258abfcd13c8, dbname=<unavailable>, username=<unavailable>) at postgres.c:5388:23
    frame #23: 0x000055b42e0f6b31 postgres`BackendRun(port=0x0000258abfc081e0) at postmaster.c:4658:2
    frame #24: 0x000055b42e0f5f0d postgres`ServerLoop [inlined] BackendStartup(port=0x0000258abfc081e0) at postmaster.c:4296:3
    frame #25: 0x000055b42e0f5ecc postgres`ServerLoop at postmaster.c:1775:7
    frame #26: 0x000055b42e0f216b postgres`PostmasterMain(argc=25, argv=0x0000258abfd00000) at postmaster.c:1431:11
    frame #27: 0x000055b42e048f06 postgres`PostgresServerProcessMain(argc=25, argv=0x0000258abfd00000) at main.c:234:3
    frame #28: 0x000055b42e049502 postgres`main + 34

Warning: Please confirm that this issue does not contain any sensitive information

  • I confirm this issue does not contain any sensitive information.
@gauravk-in gauravk-in added area/ysql Yugabyte SQL (YSQL) status/awaiting-triage Issue awaiting triage labels Aug 15, 2023
@gauravk-in gauravk-in self-assigned this Aug 15, 2023
@yugabyte-ci yugabyte-ci added kind/enhancement This is an enhancement of an existing feature priority/medium Medium priority issue labels Aug 15, 2023
gauravk-in added a commit that referenced this issue Aug 21, 2023
Summary:
A segmentation fault (SIGSEGV) can occur when the YB base scans cost model is
enabled by setting `yb_enable_base_scans_cost_model` to `TRUE`. Specifically
this can occur when a query has multiple inequality filters on more than one
index columns.

This bug was caused due to uninitialized memory. To compute the number of
nexts and seeks when multiple inequality filters are used in a query, we try to
remove all the filters on the last column with inequality filters. For each row
matching the rest of the filters a seek would be needed.

The array `numPrefixInequalityFilterOnIndexColumn` keeps a track of the number
of prefix inequality filters on each index column. Since this was uninitialized,
it can have a random value. This would cause removal of more filters in the list
than the length of the list itself, leading to a segmentation fault.

This bug could not be reproduced reliably. Queries with multiple inequality
filters on multiple columns were added.
Jira: DB-7600

Test Plan: ybd --java-test 'org.yb.pgsql.TestPgRegressPlanner'

Reviewers: tnayak, mtakahara, mihnea, yguan

Reviewed By: mtakahara, yguan

Subscribers: yql

Differential Revision: https://phorge.dev.yugabyte.com/D27803
gauravk-in added a commit that referenced this issue Aug 30, 2023
Summary:
Original commit: 1feb319 / D27803
A segmentation fault (SIGSEGV) can occur when the YB base scans cost model is
enabled by setting `yb_enable_base_scans_cost_model` to `TRUE`. Specifically
this can occur when a query has multiple inequality filters on more than one
index columns.

This bug was caused due to uninitialized memory. To compute the number of
nexts and seeks when multiple inequality filters are used in a query, we try to
remove all the filters on the last column with inequality filters. For each row
matching the rest of the filters a seek would be needed.

The array `numPrefixInequalityFilterOnIndexColumn` keeps a track of the number
of prefix inequality filters on each index column. Since this was uninitialized,
it can have a random value. This would cause removal of more filters in the list
than the length of the list itself, leading to a segmentation fault.

This bug could not be reproduced reliably. Queries with multiple inequality
filters on multiple columns were added.
Jira: DB-7600

Test Plan: ybd --java-test 'org.yb.pgsql.TestPgRegressPlanner'

Reviewers: tnayak, mtakahara, mihnea, yguan, tverona

Reviewed By: tverona

Subscribers: yql

Differential Revision: https://phorge.dev.yugabyte.com/D28200
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/ysql Yugabyte SQL (YSQL) kind/enhancement This is an enhancement of an existing feature priority/medium Medium priority issue status/awaiting-triage Issue awaiting triage
Projects
None yet
Development

No branches or pull requests

2 participants