.. _version_3.2.8:

=============
Version 3.2.8
=============

Released on 2019/04/16.

.. NOTE::

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

    We recommend that you upgrade to the latest 3.1 release before moving to
    3.2.8.

    If you want to perform a `rolling upgrade`_, your current CrateDB version
    number must be at least :ref:`version_3.2.0`. Any upgrade from a version
    prior to this will require a `full restart upgrade`_.

    When restarting, CrateDB will migrate indexes to a newer format. Depending
    on the amount of data, this may delay node start-up time.

    Please consult the :ref:`version_3.0.0_upgrade_notes` before upgrading.

.. WARNING::

    Tables that were created prior to upgrading to CrateDB 2.x will not
    function with 3.2 and must be recreated before moving to 3.2.x.

    You can recreate tables using ``COPY TO`` and ``COPY FROM`` while running a
    2.x release into a new table, or by `inserting the data into a new table`_.

    Before upgrading, you should `back up your data`_.

.. _rolling upgrade: http://crate.io/docs/crate/guide/best_practices/rolling_upgrade.html
.. _full restart upgrade: http://crate.io/docs/crate/guide/best_practices/full_restart_upgrade.html
.. _back up your data: https://crate.io/a/backing-up-and-restoring-crate/
.. _inserting the data into a new table: https://crate.io/docs/crate/reference/en/latest/admin/system-information.html#tables-need-to-be-recreated


.. rubric:: Table of Contents

.. contents::
   :local:

Changelog
=========

Fixes
-----

- Fixed the processing of ``LIMIT`` clauses within queries in the :ref:`INSERT
  INTO <ref-insert>` statement. A query like ``INSERT INTO target (SELECT *
  FROM (SELECT * FROM source LIMIT 10) t)`` could insert more than 10 rows if
  there is more than 1 node in the cluster.
  In addition, using ``LIMIT`` in the top level query of the ``INSERT INTO``
  statement is now no longer prohibited. So the query can be written as
  follows: ``INSERT INTO target (SELECT * FROM source LIMIT 10)``.

- Fixed an issue that would cause the wrong evaluation of nested sub-queries
  in cases where the inner sub-query returns a multi-value and the outer returns
  a single value result. For instance, the assignment sub-query expression in
  the following update statement
  ``UPDATE t1 SET x = (SELECT COUNT(*) FROM t2 WHERE x IN (SELECT x FROM t3))")``
  might have produced an incorrect result.
