JDBC bridge timeout happens after 100 seconds instead of 10 after upgrade to 24 version from 23

[UnamedRus]

Company or project name

No response

Describe the unexpected behaviour

JDBC timeout behavior can be configured by

     │           0 │ Production │
 7. │ http_retry_initial_backoff_ms                  │ 100   │       0 │ Min milliseconds for backoff, when retrying read via http                                                                                                               │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │        0 │ UInt64 │ 100     │           │           0 │ Production │
 8. │ http_retry_max_backoff_ms                      │ 10000 │       0 │ Max milliseconds for backoff, when retrying read via http                                                                                                               │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │        0 │ UInt64 │ 10000   │           │           0 │ Production │
 23. │ http_max_tries                                             │ 10           │       0 │ Max attempts to read via http.
                                                   │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │        0 │ UInt64  │ 10           │           │           0 │ Production │
2

How to reproduce

#68128

Error message and/or stacktrace

No response

Additional context

No response

[IsFea]

@alexey-milovidov Hi! This doesn't work even in the latest (head) versions of ClickHouse with JDBC. This is an important feature, and it seems like backward compatibility is broken. Maybe there's a chance to push a fix and backport it to 24.8?

Reproduction case:

SELECT * FROM jdbc('jdbc:postgresql://*******', 'SELECT 1/0')  

When executing this query, ClickHouse will hit the PostgreSQL server 10 times. We want to reduce the number of retry attempts (e.g., to 1) or at least properly configure timeouts for such cases.

Why this is needed:

Imagine loading a fairly large table with 1 billion records and performing something like:

SELECT number1 / number2, * ...  

If division by zero (or any other SQL execution error) happens on the last row, a lot of time will be wasted on retries before we even understand what's going wrong. This will also put unnecessary load on the source server.

[alexey-milovidov]

@IsFea, let's fix this problem; send a pull request, please.