Uploaded image for project: 'IMPALA'
  1. IMPALA
  2. IMPALA-4549

Validation of timestamp year is inconsistent about whether upper bound is 9999 or 10000

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: Impala 2.8.0
    • Fix Version/s: Impala 2.9.0
    • Component/s: Backend
    • Labels:
      None

      Description

      Boost is inconsistent in whether the maximum supported year is 9999 or 10000. This means that sometimes values with year=10000 get caught by validation and in other cases don't get caught. I think the severity is not high, since the exception-throwing validation uses the looser limit of 10000.

      I filed a bug against boost: https://svn.boost.org/trac/boost/ticket/12630

        Issue Links

          Activity

          Hide
          tarmstrong Tim Armstrong added a comment -

          IMPALA-4549: consistently treat 9999 as upper bound for timestamp year

          Previously Impala was inconsistent about whether the year 10000 was
          supported, as a result of inconsistency in boost, which reported the
          maximum year as 9999 but sometimes allowed 10000. This meant that
          Impala sometimes accepted the year 10000 and sometimes not.

          Use the patched boost version and update tests accordingly.

          Testing:
          Ran an exhaustive build.

          Change-Id: Iaf23b40833017789d879e5da7bb10384129e2d10
          Reviewed-on: http://gerrit.cloudera.org:8080/5665
          Reviewed-by: Tim Armstrong <tarmstrong@cloudera.com>
          Tested-by: Impala Public Jenkins

          Show
          tarmstrong Tim Armstrong added a comment - IMPALA-4549 : consistently treat 9999 as upper bound for timestamp year Previously Impala was inconsistent about whether the year 10000 was supported, as a result of inconsistency in boost, which reported the maximum year as 9999 but sometimes allowed 10000. This meant that Impala sometimes accepted the year 10000 and sometimes not. Use the patched boost version and update tests accordingly. Testing: Ran an exhaustive build. Change-Id: Iaf23b40833017789d879e5da7bb10384129e2d10 Reviewed-on: http://gerrit.cloudera.org:8080/5665 Reviewed-by: Tim Armstrong <tarmstrong@cloudera.com> Tested-by: Impala Public Jenkins
          Hide
          tarmstrong Tim Armstrong added a comment -

          Committed to native-toolchain:

          IMPALA-4549: consistently enforce that boost gregorian year <= 9999

          Adds a Boost patch that makes the documentation and code consistent on
          whether the max supported year is 9999 or 10000. The documentation and
          the max_date value are both 9999, so fix cases where it is 10000.

          I also filed a bug against boost https://svn.boost.org/trac/boost/ticket/12630

          Change-Id: I65e4912b407ae43e281e8fb8153c89cd12e2e237

          M buildall.sh
          A source/boost/boost-1.57.0-patches/0001-greg-year-range.patch
          2 files changed, 34 insertions, 4 deletions

          Approvals:
          Tim Armstrong: Looks good to me, approved; Verified


          To view, visit http://gerrit.cloudera.org:8080/5264
          To unsubscribe, visit http://gerrit.cloudera.org:8080/settings

          Show
          tarmstrong Tim Armstrong added a comment - Committed to native-toolchain: IMPALA-4549 : consistently enforce that boost gregorian year <= 9999 Adds a Boost patch that makes the documentation and code consistent on whether the max supported year is 9999 or 10000. The documentation and the max_date value are both 9999, so fix cases where it is 10000. I also filed a bug against boost https://svn.boost.org/trac/boost/ticket/12630 Change-Id: I65e4912b407ae43e281e8fb8153c89cd12e2e237 — M buildall.sh A source/boost/boost-1.57.0-patches/0001-greg-year-range.patch 2 files changed, 34 insertions , 4 deletions Approvals: Tim Armstrong: Looks good to me, approved; Verified – To view, visit http://gerrit.cloudera.org:8080/5264 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings

            People

            • Assignee:
              tarmstrong Tim Armstrong
              Reporter:
              tarmstrong Tim Armstrong
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development