error data input for date(CAST(value AS DATETIME)) causing high TiFlash sys CPU

[dbsid]

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

run a query include date(CAST(rv_EndDateTime.value AS DATETIME)), and make wrong input for the cast function. TiFlash need to do exception handle and capture the unwind(stack) information, which explain the high sys cpu.

with date(CAST(rv_EndDateTime.value AS DATETIME)), the query takes over 10 minutes, and causing TiFlash high sys CPU.
without date(CAST(rv_EndDateTime.value AS DATETIME)), the query take around 300 ms.

SELECT
  id,
  module_id,
  rel_namespace,
  owned_by,
  created_by,
  updated_by,
  deleted_by,
  created_at,
  updated_at,
  deleted_at
FROM
  (
    SELECT
      crd.id,
      crd.module_id,
      crd.rel_namespace,
      crd.owned_by,
      crd.created_by,
      crd.updated_by,
      crd.deleted_by,
      crd.created_at,
      crd.updated_at,
      crd.deleted_at,
      row_number() over (PARTITION by id) AS pp_rn
    FROM
      compose_record AS crd
      LEFT JOIN compose_record_value AS rv_ActivityDate ON (
        rv_ActivityDate.record_id = crd.id
        AND rv_ActivityDate.name = 'ActivityDate'
        AND rv_ActivityDate.deleted_at IS NULL
      )
      LEFT JOIN compose_record_value AS rv_EndDateTime ON (
        rv_EndDateTime.record_id = crd.id
        AND rv_EndDateTime.name = 'EndDateTime'
        AND rv_EndDateTime.deleted_at IS NULL
      )
      LEFT JOIN compose_record_value AS rv_Type ON (
        rv_Type.record_id = crd.id
        AND rv_Type.name = 'Type'
        AND rv_Type.deleted_at IS NULL
      )
    WHERE
      crd.module_id = 287514257044686682
      AND crd.rel_namespace = 287514254259603290
      AND crd.deleted_at IS NULL
      AND (
        (
          date(CAST(rv_ActivityDate.value AS DATETIME)) <= '2022-07-10T16:00:00.000Z'
          AND '2022-05-29T16:00:00.000Z' <= date(CAST(rv_EndDateTime.value AS DATETIME))
        )
        AND (rv_Type.value IS NULL)
      )
    ORDER BY
      id ASC
  ) AS base
WHERE
  pp_rn = 1
LIMIT
  501;

2. What did you expect to see? (Required)

no high cpu

3. What did you see instead (Required)

high TiFlash sys CPU

4. What is your TiFlash version? (Required)

v6.1

[zanmato1984]

We should avoid using exception to pass error during function evaluation. We'd rather use return value to do that.

[fuzhe1989]

@zanmato1984 before achieving this, how about not print stacktrace for normal exceptions (only let BaseDaemon print stacetrace)? Such information is almost useless for debuging if we print enough logs at the throw points.

[windtalker]

@zanmato1984 before achieving this, how about not print stacktrace for normal exceptions (only let BaseDaemon print stacetrace)? Such information is almost useless for debuging if we print enough logs at the throw points.

But here we don't print the stacktrace, it is the stack unwind that causes the hight sys cpu usage.

[fuzhe1989]

@windtalker Yes that's what I meant, not print here also means not to unwind.

[fuzhe1989]

@windtalker FYI, stacktrace unwind is disabled by default in my previous team (only enabled for fatal errors).