Skip to content

branch-4.0: [fix](be) Handle legacy DecimalV2 segments with missing precision/frac (#63569)#63581

Open
jacktengg wants to merge 1 commit into
apache:branch-4.0from
jacktengg:4.0-260525-pick
Open

branch-4.0: [fix](be) Handle legacy DecimalV2 segments with missing precision/frac (#63569)#63581
jacktengg wants to merge 1 commit into
apache:branch-4.0from
jacktengg:4.0-260525-pick

Conversation

@jacktengg
Copy link
Copy Markdown
Contributor

Pick: #63569

Problem Summary: After upgrading from 3.1.4 to 4.0.4, queries on DecimalV2 columns fail with:

[INTERNAL_ERROR]meet invalid precision: real_precision=0,
max_decimal_precision=27, min_decimal_precision=1

Root cause: Segments written by Doris < 2.1.0 (before #26572) do not persist precision/frac in ColumnMetaPB; they default to 0 when read back. Since #35222, DataTypeFactory passes those raw values as original_precision/original_scale into DataTypeDecimalV2, which calls check_type_precision(0) and throws. 3.1.4 was unaffected because the old code hardcoded (27, 9).

Fix: In _create_primitive_data_type for OLAP_FIELD_TYPE_DECIMAL, when precision is not positive (legacy segment), pass UINT32_MAX to DataTypeDecimalV2 to signal that the original precision/scale are unknown. DecimalScaleInfo<TYPE_DECIMALV2> already treats UINT32_MAX as 'unknown' and falls back to the in-memory (27, 9) representation in get_original_precision()/get_original_scale().

Fix "meet invalid precision: real_precision=0" when querying DecimalV2 columns on segments written by Doris versions older than 2.1.0.

  • Test: Unit Test
    • Added DataTypeDecimalTest.create_decimalv2_from_legacy_tablet_column covering: legacy TabletColumn (unset precision/frac), modern TabletColumn with decimal(26,6), and legacy segment_v2::ColumnMetaPB with default-0 precision/frac.
  • Behavior changed: No
  • Does this need documentation: No

What problem does this PR solve?

Issue Number: close #xxx

Related PR: #xxx

Problem Summary:

Release note

None

Check List (For Author)

  • Test

    • Regression test
    • Unit Test
    • Manual test (add detailed scripts or steps below)
    • No need to test or manual test. Explain why:
      • This is a refactor/code format and no logic has been changed.
      • Previous test can cover this change.
      • No code files have been changed.
      • Other reason
  • Behavior changed:

    • No.
    • Yes.
  • Does this need documentation?

    • No.
    • Yes.

Check List (For Reviewer who merge this PR)

  • Confirm the release note
  • Confirm test cases
  • Confirm document
  • Add branch pick label

@jacktengg
Copy link
Copy Markdown
Contributor Author

run buildall

@jacktengg
Copy link
Copy Markdown
Contributor Author

run buildall

…recision/frac (apache#63569)

Pick: apache#63569

Problem Summary: After upgrading from 3.1.4 to 4.0.4, queries on
DecimalV2 columns fail with:

    [INTERNAL_ERROR]meet invalid precision: real_precision=0,
    max_decimal_precision=27, min_decimal_precision=1

Root cause: Segments written by Doris < 2.1.0 (before apache#26572) do not
persist precision/frac in ColumnMetaPB; they default to 0 when read
back. Since apache#35222, DataTypeFactory passes those raw values as
original_precision/original_scale into DataTypeDecimalV2, which calls
check_type_precision(0) and throws. 3.1.4 was unaffected because the
old code hardcoded (27, 9).

Fix: In _create_primitive_data_type for OLAP_FIELD_TYPE_DECIMAL, when
precision is not positive (legacy segment), pass UINT32_MAX to
DataTypeDecimalV2 to signal that the original precision/scale are
unknown. DecimalScaleInfo<TYPE_DECIMALV2> already treats UINT32_MAX as
'unknown' and falls back to the in-memory (27, 9) representation in
get_original_precision()/get_original_scale().

Fix "meet invalid precision: real_precision=0" when querying DecimalV2
columns on segments written by Doris versions older than 2.1.0.

- Test: Unit Test
    - Added DataTypeDecimalTest.create_decimalv2_from_legacy_tablet_column
      covering: legacy TabletColumn (unset precision/frac), modern
      TabletColumn with decimal(26,6), and legacy segment_v2::ColumnMetaPB
      with default-0 precision/frac.
- Behavior changed: No
- Does this need documentation: No

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant