.. _version_6.1.3:

=============
Version 6.1.3
=============

Released on 2026-02-03.

.. NOTE::

    If you are upgrading a cluster, you must be running CrateDB 5.0.0 or higher
    before you upgrade to 6.1.3.

    We recommend that you upgrade to the latest 6.0 release before moving to
    6.1.3.

    A rolling upgrade from >= 6.0.2 to 6.1.3 is supported.
    Before upgrading, you should `back up your data`_.

.. WARNING::

    Tables that were created before CrateDB 5.x will not function with 6.x
    and must be recreated before moving to 6.x.x.

    You can recreate tables using ``COPY TO`` and ``COPY FROM`` or by
    `inserting the data into a new table`_.

.. _back up your data: https://cratedb.com/docs/crate/reference/en/latest/admin/snapshots.html
.. _inserting the data into a new table: https://cratedb.com/docs/crate/reference/en/latest/admin/system-information.html#tables-need-to-be-recreated

.. rubric:: Table of contents

.. contents::
   :local:


See the :ref:`version_6.1.0` release notes for a full list of changes in the 6.1
series.

Fixes
=====

- Fixed an issue that caused ``INSERT INTO`` statements into columns of type
  ``ARRAY(OBJECT(DYNAMIC))`` to fail with an
  ``UnsupportedFeatureException[null]`` if it resulted in the addition of new
  columns to the table schema and if the objects within the array contained
  mixed types like in ``[{"x": 1}, {"x": null}]``.

- Fixed an issue that allowed inserting ``NULL`` values into child columns of
  ``ARRAY(OBJECT)`` columns despite ``NOT NULL`` constraint on those child
  columns if a sibling column had a value.

- Fixed an issue that prevented ``ILIKE`` from matching records with text
  containing newline characters.

- Fixed an issue that could lead to a ``Couldn't create executionContexts from
  [...] Can't handle Symbol`` error when running ``SELECT`` queries involving
  expressions using multiple columns like ``CASE`` and a ``LIMIT`` clause.

- Changed :ref:`hyperloglog_distinct <aggregation-hyperloglog-distinct>` to return
  ``0`` instead of ``NULL`` if using a ``FILTER`` clause that doesn't match any
  records - to be consistent with a global ``WHERE`` and ``COUNT``.

- Fixed a regression introduced in :ref:`version_6.1.0` that could lead to
  mixing partial success results with error message in the response from the
  ``HTTP`` endpoint.

- Fixed an issue causing memory leaks if requests to the ``HTTP`` endpoint
  failed due to a missing :ref:`HBA <admin_hba>` entry or wrong credentials.

- Fixed an issue that caused direct memory under-accounting, potentially leading
  to an ``OutOfMemoryError`` when a large result set was returned by the
  ``HTTP`` endpoint.

- Fixed a regression introduced with :ref:`version_6.0.0` that led to wrong
  results when mixing ``CROSS JOIN`` and ``INNER JOIN`` on a condition with a
  :ref:`CASE<scalar-case-when-then-end>` referring to one of the cross joined
  tables. e.g.::

    SELECT * FROM t1, t0
    INNER JOIN (SELECT 1 AS col0) AS sub0
    ON (CASE sub0.col0 WHEN sub0.col0 THEN t0.c0 ELSE false END)

- Fixed an issue resulting in a non matching :ref:`sql_dql_is_null` predicate
  when NULL values are inserted into a new sub-column of a
  :ref:`type-object` column with dynamic mapping enabled. E.g.::

    CREATE TABLE t (o OBJECT(DYNAMIC));
    INSERT INTO t (o) VALUES ({"a": NULL});
    SELECT * FROM t WHERE o['a'] IS NULL;  -- now returns the row

- Fixed a regression introduced in :ref:`version_6.0.0` that caused
  :ref:`sql-insert` statements with writes into columns of type
  :ref:`OBJECT(DYNAMIC) <type-object-columns-dynamic>` to fail with an NPE if
  a nested object value containing elements with ``NULL`` values was inserted
  before. Example::

    CREATE TABLE t1 (obj OBJECT(DYNAMIC));
    INSERT INTO t1 (obj) VALUES ({a = {b = NULL}});
    INSERT INTO t1 (obj) VALUES ({a = {c = 1}});

- Fixed an issue that caused under-accounting of memory usage of some queries
  stored in cache. It affected cache eviction that is depending on query memory
  usage, potentially leading to an ``OutOfMemoryError``.

- Fixed an issue with users being able to execute
  :ref:`user defined functions <user-defined-functions>`, even if they lacked
  privileges on the schema under which a ``UDF`` is defined. Now ``DQL``
  :ref:`privilege <administration-privileges>` on the schema is required.

- Fixed a regression introduced in :ref:`version_6.0.0` that caused statements
  ``SELECT unnest(obj['arr'])['subcol']`` to fail with a ``ClassCastException``
  if ``obj`` column had a type :ref:`IGNORED <type-object-columns-ignored>`
  and ``subcol`` was missing in the record. Error was thrown regardless of the
  value specified in :ref:`conf-session-error_on_unknown_object_key`.
  Now it returns ``NULL`` if :ref:`conf-session-error_on_unknown_object_key` is
  set to ``false`` and throws ``ColumnUnknownException`` if it has default
  value ``true``.

- Improved error message thrown when providing empty value for configuration
  settings, e.g.:

      $> bin/crate -Cauth.host_based.enabled
      $> bin/crate -Cauth.host_based.enabled=

- Fixed an issue that caused incorrect results when using an ``Anti-Join``
  (``WHERE NOT EXISTS``) with a ``WHERE`` clause containing ``BOOLEAN`` typed
  columns combined by an ``OR`` operator. Example::

    SELECT * FROM t1 WHERE NOT EXISTS
      (SELECT 1 FROM (SELECT c2 FROM t1 WHERE bool_col) AS sub0
       WHERE t1.bool_col OR t1.bool_col);

- Fixed a regression introduced in :ref:`version_6.0.0` with upgrade to
  Lucene 10.2 that caused increase in IOPS and slow recovery times on node
  restarts. Flag mentioned in :ref:`version_6.0.0_breaking_changes` and
  :ref:`version_6.1.0_breaking_changes` is already set to ``NORMAL`` starting
  from this version and won't be needed at all starting from CrateDB 6.2.0.

- Fixed a regression introduced in :ref:`version_6.0.0` that caused nested path
  accesses on ``ARRAY(OBJECT)`` columns returned by a sub-select using a
  ``UNNEST`` function to either fail with a ``ColumnUnknownException`` or
  return incorrect results as wrong child-columns are used. Example::

    SELECT obj_arr['child_obj']['id'] AS id
    FROM (
      SELECT unnest(
        [ {child_obj = { id = 'correct_id'}, id='wrong_id'} ]
      ) AS obj_arr
    ) AS sub1
    --> now returns 'correct_id' instead of returning 'wrong_id'

- Fixed an issue that caused inserts to fail with a
  ``UnsupportedFeatureException`` error if a sub-column of a ``OBJECT`` typed
  column, previously created with a ``NULL`` value, is then inserted using a
  non-NULL value and such using a concrete data type.
