Skip to content
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 12 additions & 2 deletions docs/release-notes/known-issues.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,10 +8,20 @@ mapped_pages:
Known issues are significant defects or limitations that may impact your implementation. These issues are actively being worked on and will be addressed in a future release. Review the Elasticsearch known issues to help you make informed decisions, such as upgrading to a new version.

## 9.0.3 [elasticsearch-9.0.3-known-issues]
A bug in the merge scheduler in Elasticsearch 9.0.3 may prevent shards from closing when there isn’t enough disk space to complete a merge. As a result, operations such as closing or relocating an index may hang until sufficient disk space becomes available.
* A bug in the merge scheduler in Elasticsearch 9.0.3 may prevent shards from closing when there isn’t enough disk space to complete a merge. As a result, operations such as closing or relocating an index may hang until sufficient disk space becomes available.
To mitigate this issue, the disk space checker is disabled by default in 9.0.3 by setting `indices.merge.disk.check_interval` to `0` seconds. Manually enabling this setting is not recommended.

This issue is planned to be fixed in future patch release [#129613](https://github.com/elastic/elasticsearch/pull/129613)
This issue is planned to be fixed in future patch release [#129613](https://github.com/elastic/elasticsearch/pull/129613)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@leemthompo the problem is there since 8.16, so also in 9.0.0.
Should the note be in 9.0.0 section instead? What is the best practice here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Sorry, I mean the new note of course, two lines below...)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@luigidellaquila I think the best practice is to add the known issue to all affected versions

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this might be hard to do for all the 8.x versions, but probably manageable for the 9.x versions

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 I wonder if we added a known issues section (or link) in the ESQL limitations page that would be helpful too? Just thinking out loud

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the best practice is to add the known issue to all affected versions

OK, I'm adding the same note in the 9.0.0 section.

I wonder if we added a known issues section (or link) in the ESQL limitations page that would be helpful too?

I think it makes sense. Probably, in terms of maintenance effort, a link to the known issues is easier to manage. My concern is that we could end up with misalignments if we duplicate information.

I'm adding a new section, please have a look if you have a chance.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM


* A bug in ES|QL STATS command may lead to wrong results. The bug only happens in a very specific case, ie. with `STATS ... BY keyword1, keyword2`:
exactly two grouping fields, both keywords, where the first field has high cardinality (more than 65k distinct values).

The issue is described in detail in [this issue](https://github.com/elastic/elasticsearch/issues/130644).
The problem was introduced in 8.16.0 and [fixed](https://github.com/elastic/elasticsearch/pull/130705) in 8.17.9, 8.18.7, 9.0.4,

Possible work-arounds are:
* switching the order of the grouping keys (eg. `STATS ... BY keyword2, keyword1`, if the `keyword2` has a lower cardinality)
* reducing the grouping key cardinality, filtering out values before STATS.

## 9.0.0 [elasticsearch-9.0.0-known-issues]
* Elasticsearch on Windows might fail to start, or might forbid some file-related operations, when referencing paths with a case different from the one stored by the filesystem. Windows treats paths as case-insensitive, but the filesystem stores them with case. Entitlements, the new security system used by Elasticsearch, treat all paths as case-sensitive, and can therefore prevent access to a path that should be accessible.
Expand Down
Loading