Version 6.3.3 - Unreleased¶
Note
In development. 6.3.3 isn’t released yet. These are the release notes for the upcoming release.
Note
If you are upgrading a cluster, you must be running CrateDB 5.0.0 or higher before you upgrade to 6.3.3.
We recommend that you upgrade to the latest 6.2 release before moving to 6.3.3.
A rolling upgrade from >= 6.2.0 to 6.3.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.
Table of contents
See the Version 6.3.0 release notes for a full list of changes in the 6.3 series.
Fixes¶
Changed the PostgreSQL wire format text encoding for
TIMESTAMP WITHOUT TIME ZONEto not include an UTC offset (+00) to match PostgreSQL and fix compatibility issues withpgx.Fixed an issue where RESTORE SNAPSHOT of a partition into a table with an incompatible schema would silently succeed and produce unreadable data. CrateDB now rejects such restores with a clear error when the snapshot and target table schemas do not match.
Fixed an issue that caused multiple empty statements like ;; to result in a parsing failure instead of returning empty statement results when executed via the simple mode of the PostgreSQL wire protocol.
Fixed an issue that caused RESTORE SNAPSHOT to return
RESTORE OKeven if some shards failed to restore (for example, due to exceeded disk watermarks). It now fails with aSnapshotRestoreException.Fixed intermittent
UDFresolution failures when upgrading metadata from a remote cluster, for example during logical replication.Fixed an issue that caused nodes to fail to start when parsing persisted mappings for tables containing columns of type
uuid.Fixed a regression introduced with Version 6.0.0, leading to stuck
DROP SNAPSHOTandCREATE SNAPSHOTqueries.Fixed an issue causing cache to retain some heavy structures, potentially leading to an
OutOfMemoryError.Fixed an issue causing
COUNTqueries on a partitioned table to fail withShardNotFoundExceptionerror if some partition shards were temporarily unavailable.