/
3.0.3.rst
100 lines (67 loc) · 3.46 KB
/
3.0.3.rst
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
.. _version_3.0.3:
=============
Version 3.0.3
=============
Released on 2018/06/29.
.. NOTE::
If you are upgrading a cluster, you must be running CrateDB 2.0.4 or higher
before you upgrade to 3.0.3.
We recommend that you upgrade to the latest 2.3 release before moving to
3.0.3.
If you want to perform a `rolling upgrade`_, your current CrateDB version
number must be at least :ref:`version_3.0.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.0 and must be recreated before moving to 3.0.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`_.
.. WARNING::
Before upgrading, you should `back up your data`_.
.. _rolling upgrade: https://crate.io/docs/crate/howtos/en/latest/admin/rolling-upgrade.html
.. _full restart upgrade: https://crate.io/docs/crate/howtos/en/latest/admin/full-restart-upgrade.html
.. _back up your data: https://crate.io/docs/crate/reference/en/latest/admin/snapshots.html
.. _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
=========
Changes
-------
- Added settings ``s3.client.default.access_key`` and
``s3.client.default.secret_key`` which can be used to set default credentials
for S3 repositories, if they are not passed as parameters to the ``CREATE
REPOSITORY`` SQL statement.
- Implemented a thread-utilization down-scaling logic which dynamically adapts
the number of threads used for ``SELECT`` queries to avoid running into
``RejectedExcecution`` errors if there are many shards per node involved in
the queries.
- Improved execution of ``DELETE`` and ``UPDATE`` queries, which should
generally result in an increased performance for queries which only match a
subset of the rows and avoid ``CircuitBreakingException`` errors. But it
might result in a slight performance decrease if queries match all or almost
all records.
Fixes
-----
- Fixed an issue where the Admin UI was not loaded when it was served from
another location than ``/`` resulting in a blank browser canvas.
- Made table setting ``blocks.read_only_allow_delete`` configurable for
partitioned tables.
- Improved performance for :ref:`expressions <gloss-expression>` involving
literal type conversions, e.g. ``select count(*) from users group by name
having max(bytes) = 4``.
- Fixed an issue which could result in lost entries at the ``sys.jobs_log`` and
``sys.operations_log`` tables when the related settings are changed while
entries are written.
- Fixed a dependency issue with the bundled ``crash`` that caused the
application to be unable to connect to the server.
- Fixed an issue that could prevent PostgreSQL clients from receiving an error
and therefore getting stuck.
- Fixed an issue that would cause a ``CAST`` from ``TIMESTAMP`` to ``LONG`` to
be ignored.
- Handle ``STRING_ARRAY`` as argument type for :ref:`user-defined functions
<user-defined-functions>` correctly to prevent an ``ArrayStoreException``.