additional fixes

Author: dhtclk

docs/_snippets/_S3_authentication_and_bucket.md

@@ -22,7 +22,7 @@ import s3_h from '@site/static/images/_snippets/s3/s3-h.png';
 This article demonstrates the basics of how to configure an AWS IAM user, create an S3 bucket and configure ClickHouse to use the bucket as an S3 disk. You should work with your security team to determine the permissions to be used, and consider these as a starting point.
 ### Create an AWS IAM user {#create-an-aws-iam-user}
 In this procedure, we'll be creating a service account user, not a login user.
-1.  Log into the AWS IAM Management Console.
+1. Log into the AWS IAM Management Console.
 2. In "users", select **Add users**
 <Image size="md" img={s3_1} alt="AWS IAM Management Console - Adding a new user" border force/>
 3. Enter the user name and set the credential type to **Access key - Programmatic access** and select **Next: Permissions**

docs/_snippets/_users-and-roles-common.md

@@ -111,49 +111,49 @@ With this set of examples:
 
     Roles are used to define groups of users for certain privileges instead of managing each user separately.
 
-1.  Create a role to restrict users of this role to only see `column1` in database `db1` and `table1`:
+1. Create a role to restrict users of this role to only see `column1` in database `db1` and `table1`:
 
     ```sql
     CREATE ROLE column1_users;
     ```
 
-2.  Set privileges to allow view on `column1`
+2. Set privileges to allow view on `column1`
 
     ```sql
     GRANT SELECT(id, column1) ON db1.table1 TO column1_users;
     ```
 
-3.  Add the `column_user` user to the `column1_users` role
+3. Add the `column_user` user to the `column1_users` role
 
     ```sql
     GRANT column1_users TO column_user;
     ```
 
-4.  Create a role to restrict users of this role to only see selected rows, in this case, only rows containing `A` in `column1`
+4. Create a role to restrict users of this role to only see selected rows, in this case, only rows containing `A` in `column1`
 
     ```sql
     CREATE ROLE A_rows_users;
     ```
 
-5.  Add the `row_user` to the `A_rows_users` role
+5. Add the `row_user` to the `A_rows_users` role
 
     ```sql
     GRANT A_rows_users TO row_user;
     ```
 
-6.  Create a policy to allow view on only where `column1` has the values of `A`
+6. Create a policy to allow view on only where `column1` has the values of `A`
 
     ```sql
     CREATE ROW POLICY A_row_filter ON db1.table1 FOR SELECT USING column1 = 'A' TO A_rows_users;
     ```
 
-7.  Set privileges to the database and table
+7. Set privileges to the database and table
 
     ```sql
     GRANT SELECT(id, column1, column2) ON db1.table1 TO A_rows_users;
     ```
 
-8.  grant explicit permissions for other roles to still have access to all rows
+8. grant explicit permissions for other roles to still have access to all rows
 
     ```sql
     CREATE ROW POLICY allow_other_users_filter

docs/about-us/distinctive-features.md

@@ -73,9 +73,9 @@ In ClickHouse "low latency" means that queries can be processed without delay an
 
 ClickHouse provides various ways to trade accuracy for performance:
 
-1.  Aggregate functions for approximated calculation of the number of distinct values, medians, and quantiles.
-2.  Running a query based on a part ([SAMPLE](../sql-reference/statements/select/sample.md)) of data and getting an approximated result. In this case, proportionally less data is retrieved from the disk.
-3.  Running an aggregation for a limited number of random keys, instead of for all keys. Under certain conditions for key distribution in the data, this provides a reasonably accurate result while using fewer resources.
+1. Aggregate functions for approximated calculation of the number of distinct values, medians, and quantiles.
+2. Running a query based on a part ([SAMPLE](../sql-reference/statements/select/sample.md)) of data and getting an approximated result. In this case, proportionally less data is retrieved from the disk.
+3. Running an aggregation for a limited number of random keys, instead of for all keys. Under certain conditions for key distribution in the data, this provides a reasonably accurate result while using fewer resources.
 
 ## Adaptive join algorithm {#adaptive-join-algorithm}
 
@@ -93,6 +93,6 @@ ClickHouse implements user account management using SQL queries and allows for [
 
 ## Features that can be considered disadvantages {#clickhouse-features-that-can-be-considered-disadvantages}
 
-1.  No full-fledged transactions.
-2.  Lack of ability to modify or delete already inserted data with a high rate and low latency. There are batch deletes and updates available to clean up or modify data, for example, to comply with [GDPR](https://gdpr-info.eu).
-3.  The sparse index makes ClickHouse not so efficient for point queries retrieving single rows by their keys.
+1. No full-fledged transactions.
+2. Lack of ability to modify or delete already inserted data with a high rate and low latency. There are batch deletes and updates available to clean up or modify data, for example, to comply with [GDPR](https://gdpr-info.eu).
+3. The sparse index makes ClickHouse not so efficient for point queries retrieving single rows by their keys.

docs/architecture/cluster-deployment.md

@@ -14,10 +14,10 @@ By going through this tutorial, you'll learn how to set up a simple ClickHouse c
 
 This ClickHouse cluster will be a homogeneous cluster. Here are the steps:
 
-1.  Install ClickHouse server on all machines of the cluster
-2.  Set up cluster configs in configuration files
-3.  Create local tables on each instance
-4.  Create a [Distributed table](../engines/table-engines/special/distributed.md)
+1. Install ClickHouse server on all machines of the cluster
+2. Set up cluster configs in configuration files
+3. Create local tables on each instance
+4. Create a [Distributed table](../engines/table-engines/special/distributed.md)
 
     A [distributed table](../engines/table-engines/special/distributed.md) is a kind of "view" to the local tables in a ClickHouse cluster. A SELECT query from a distributed table executes using resources of all cluster's shards. You may specify configs for multiple clusters and create multiple distributed tables to provide views for different clusters.
 

docs/cloud/changelogs/24_02.md

@@ -19,7 +19,7 @@ sidebar_position: 8
 * The obsolete in-memory data parts have been deprecated since version 23.5 and have not been supported since version 23.10. Now the remaining code is removed. Continuation of [#55186](https://github.com/ClickHouse/ClickHouse/issues/55186) and [#45409](https://github.com/ClickHouse/ClickHouse/issues/45409). It is unlikely that you have used in-memory data parts because they were available only before version 23.5 and only when you enabled them manually by specifying the corresponding SETTINGS for a MergeTree table. To check if you have in-memory data parts, run the following query: `SELECT part_type, count() FROM system.parts GROUP BY part_type ORDER BY part_type`. To disable the usage of in-memory data parts, do `ALTER TABLE ... MODIFY SETTING min_bytes_for_compact_part = DEFAULT, min_rows_for_compact_part = DEFAULT`. Before upgrading from old ClickHouse releases, first check that you don't have in-memory data parts. If there are in-memory data parts, disable them first, then wait while there are no in-memory data parts and continue the upgrade. [#61127](https://github.com/ClickHouse/ClickHouse/pull/61127) ([Alexey Milovidov](https://github.com/alexey-milovidov)).
 * Forbid `SimpleAggregateFunction` in `ORDER BY` of `MergeTree` tables (like `AggregateFunction` is forbidden, but they are forbidden because they are not comparable) by default (use `allow_suspicious_primary_key` to allow them). [#61399](https://github.com/ClickHouse/ClickHouse/pull/61399) ([Azat Khuzhin](https://github.com/azat)).
 * ClickHouse allows arbitrary binary data in the String data type, which is typically UTF-8. Parquet/ORC/Arrow Strings only support UTF-8. That's why you can choose which Arrow's data type to use for the ClickHouse String data type - String or Binary. This is controlled by the settings, `output_format_parquet_string_as_string`, `output_format_orc_string_as_string`, `output_format_arrow_string_as_string`. While Binary would be more correct and compatible, using String by default will correspond to user expectations in most cases. Parquet/ORC/Arrow supports many compression methods, including lz4 and zstd. ClickHouse supports each and every compression method. Some inferior tools lack support for the faster `lz4` compression method, that's why we set `zstd` by default. This is controlled by the settings `output_format_parquet_compression_method`, `output_format_orc_compression_method`, and `output_format_arrow_compression_method`. We changed the default to `zstd` for Parquet and ORC, but not Arrow (it is emphasized for low-level usages). [#61817](https://github.com/ClickHouse/ClickHouse/pull/61817) ([Alexey Milovidov](https://github.com/alexey-milovidov)).
-*  Fix for the materialized view security issue, which allowed a user to insert into a table without required grants for that. Fix validates that the user has permission to insert not only into a materialized view but also into all underlying tables. This means that some queries, which worked before, now can fail with Not enough privileges. To address this problem, the release introduces a new feature of SQL security for views [https://clickhouse.com/docs/sql-reference/statements/create/view#sql_security](/sql-reference/statements/create/view#sql_security). [#54901](https://github.com/ClickHouse/ClickHouse/pull/54901) ([pufit](https://github.com/pufit))
+* Fix for the materialized view security issue, which allowed a user to insert into a table without required grants for that. Fix validates that the user has permission to insert not only into a materialized view but also into all underlying tables. This means that some queries, which worked before, now can fail with Not enough privileges. To address this problem, the release introduces a new feature of SQL security for views [https://clickhouse.com/docs/sql-reference/statements/create/view#sql_security](/sql-reference/statements/create/view#sql_security). [#54901](https://github.com/ClickHouse/ClickHouse/pull/54901) ([pufit](https://github.com/pufit))
 
 #### New feature {#new-feature}
 * Topk/topkweighed support mode, which return count of values and it's error. [#54508](https://github.com/ClickHouse/ClickHouse/pull/54508) ([UnamedRus](https://github.com/UnamedRus)).

docs/faq/operations/production.md

@@ -10,8 +10,8 @@ description: 'This page provides guidance on which ClickHouse version to use in
 
 First of all, let's discuss why people ask this question in the first place. There are two key reasons:
 
-1.  ClickHouse is developed with pretty high velocity, and usually there are 10+ stable releases per year. That makes a wide range of releases to choose from, which is not so trivial of a choice.
-2.  Some users want to avoid spending time figuring out which version works best for their use case and just follow someone else's advice.
+1. ClickHouse is developed with pretty high velocity, and usually there are 10+ stable releases per year. That makes a wide range of releases to choose from, which is not so trivial of a choice.
+2. Some users want to avoid spending time figuring out which version works best for their use case and just follow someone else's advice.
 
     The second reason is more fundamental, so we'll start with that one and then get back to navigating through various ClickHouse releases.
 
@@ -39,19 +39,19 @@ Here are some key points to get reasonable fidelity in a pre-production environm
 
     When you have your pre-production environment and testing infrastructure in place, choosing the best version is straightforward:
 
-1.  Routinely run your automated tests against new ClickHouse releases. You can do it even for ClickHouse releases that are marked as `testing`, but going forward to the next steps with them is not recommended.
-2.  Deploy the ClickHouse release that passed the tests to pre-production and check that all processes are running as expected.
-3.  Report any issues you discovered to [ClickHouse GitHub Issues](https://github.com/ClickHouse/ClickHouse/issues).
-4.  If there were no major issues, it should be safe to start deploying ClickHouse release to your production environment. Investing in gradual release automation that implements an approach similar to [canary releases](https://martinfowler.com/bliki/CanaryRelease.html) or [green-blue deployments](https://martinfowler.com/bliki/BlueGreenDeployment.html) might further reduce the risk of issues in production.
+1. Routinely run your automated tests against new ClickHouse releases. You can do it even for ClickHouse releases that are marked as `testing`, but going forward to the next steps with them is not recommended.
+2. Deploy the ClickHouse release that passed the tests to pre-production and check that all processes are running as expected.
+3. Report any issues you discovered to [ClickHouse GitHub Issues](https://github.com/ClickHouse/ClickHouse/issues).
+4. If there were no major issues, it should be safe to start deploying ClickHouse release to your production environment. Investing in gradual release automation that implements an approach similar to [canary releases](https://martinfowler.com/bliki/CanaryRelease.html) or [green-blue deployments](https://martinfowler.com/bliki/BlueGreenDeployment.html) might further reduce the risk of issues in production.
 
     As you might have noticed, there's nothing specific to ClickHouse in the approach described above - people do that for any piece of infrastructure they rely on if they take their production environment seriously.
 
 ## How to choose between ClickHouse releases? {#how-to-choose-between-clickhouse-releases}
 
 If you look into the contents of the ClickHouse package repository, you'll see two kinds of packages:
 
-1.  `stable`
-2.  `lts` (long-term support)
+1. `stable`
+2. `lts` (long-term support)
 
     Here is some guidance on how to choose between them:
 

docs/guides/best-practices/query-optimization.md

@@ -301,9 +301,9 @@ Summarize in the table for easy reading.
 
 Let's understand a bit better what the queries achieve.
 
--   Query 1 calculates the distance distribution in rides with an average speed of over 30 miles per hour.
--   Query 2 finds the number and average cost of rides per week.
--   Query 3 calculates the average time of each trip in the dataset.
+- Query 1 calculates the distance distribution in rides with an average speed of over 30 miles per hour.
+- Query 2 finds the number and average cost of rides per week.
+- Query 3 calculates the average time of each trip in the dataset.
 
     None of these queries are doing very complex processing, except the first query that calculates the trip time on the fly every time the query executes. However, each of these queries takes more than one second to execute, which, in the ClickHouse world, is a very long time. We can also note the memory usage of these queries; more or less 400 Mb for each query is quite a lot of memory. Also, each query appears to read the same number of rows (i.e., 329.04 million). Let's quickly confirm how many rows are in this table.
 
@@ -315,7 +315,7 @@ Let's understand a bit better what the queries achieve.
   Query id: 733372c5-deaf-4719-94e3-261540933b23
 
      ┌───count()─┐
- 1. │ 329044175 │ -- 329.04 million
+  1. │ 329044175 │ -- 329.04 million
      └───────────┘
   ```
 
@@ -600,9 +600,9 @@ Choosing the correct set of primary keys is a complex topic, and it might requir
 
 For now, we're going to follow these simple practices:
 
--   Use fields that are used to filter in most queries
--   Choose columns with lower cardinality first
--   Consider a time-based component in your primary key, as filtering by time on a timestamp dataset is pretty common.
+- Use fields that are used to filter in most queries
+- Choose columns with lower cardinality first
+- Consider a time-based component in your primary key, as filtering by time on a timestamp dataset is pretty common.
 
     In our case, we will experiment with the following primary keys: `passenger_count`, `pickup_datetime`, and `dropoff_datetime`.
 

docs/guides/best-practices/sparse-primary-indexes.md

@@ -750,7 +750,7 @@ As an example for both cases we will assume:
 
     There are three different scenarios for the granule selection process for our abstract sample data in the diagram above:
 
-1.  Index mark 0 for which the **URL value is smaller than W3 and for which the URL value of the directly succeeding index mark is also smaller than W3** can be excluded because mark 0, and 1 have the same UserID value. Note that this exclusion-precondition ensures that granule 0 is completely composed of U1 UserID values so that ClickHouse can assume that also the maximum URL value in granule 0 is smaller than W3 and exclude the granule.
+1. Index mark 0 for which the **URL value is smaller than W3 and for which the URL value of the directly succeeding index mark is also smaller than W3** can be excluded because mark 0, and 1 have the same UserID value. Note that this exclusion-precondition ensures that granule 0 is completely composed of U1 UserID values so that ClickHouse can assume that also the maximum URL value in granule 0 is smaller than W3 and exclude the granule.
 
 2. Index mark 1 for which the **URL value is smaller (or equal) than W3 and for which the URL value of the directly succeeding index mark is greater (or equal) than W3** is selected because it means that granule 1 can possibly contain rows with URL W3.
 

docs/guides/developer/mutations.md

@@ -31,23 +31,23 @@ ALTER TABLE [<database>.]<table> UPDATE <column> = <expression> WHERE <filter_ex
 
 **Examples**:
 
- 1.  A mutation like this allows updating replacing `visitor_ids` with new ones using a dictionary lookup:
+1. A mutation like this allows updating replacing `visitor_ids` with new ones using a dictionary lookup:
 
      ```sql
      ALTER TABLE website.clicks
      UPDATE visitor_id = getDict('visitors', 'new_visitor_id', visitor_id)
      WHERE visit_date < '2022-01-01'
      ```
 
-2.   Modifying multiple values in one command can be more efficient than multiple commands:
+2. Modifying multiple values in one command can be more efficient than multiple commands:
 
      ```sql
      ALTER TABLE website.clicks
      UPDATE url = substring(url, position(url, '://') + 3), visitor_id = new_visit_id
      WHERE visit_date < '2022-01-01'
      ```
 
-3.  Mutations can be executed `ON CLUSTER` for sharded tables:
+3. Mutations can be executed `ON CLUSTER` for sharded tables:
 
      ```sql
      ALTER TABLE clicks ON CLUSTER main_cluster
@@ -76,7 +76,7 @@ The `<filter_expr>` should return a UInt8 value for each row of data.
     ALTER TABLE website.clicks DELETE WHERE visitor_id in (253, 1002, 4277)
     ```
 
-2.  What does this query alter?
+2. What does this query alter?
     ```sql
     ALTER TABLE clicks ON CLUSTER main_cluster DELETE WHERE visit_date < '2022-01-02 15:00:00' AND page_id = '573'
     ```

docs/guides/sre/configuring-ssl.md

@@ -236,7 +236,7 @@ For a full explanation of all options, visit https://clickhouse.com/docs/operati
 ## 5. Configure SSL-TLS interfaces on ClickHouse nodes {#5-configure-ssl-tls-interfaces-on-clickhouse-nodes}
 The settings below are configured in the ClickHouse server `config.xml`
 
-1.  Set the display name for the deployment (optional):
+1. Set the display name for the deployment (optional):
     ```xml
     <display_name>clickhouse</display_name>
     ```