[
https://issues.apache.org/jira/browse/IGNITE-24340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-24340:
---------------------------------------
Description:
Here is a scenario (requires implicit PKs):
1. CREATE TABLE integers(i INTEGER)
2. INSERT INTO integers VALUES (0), (0), (0), (0)
3. Repeat the following query a few times (without using explicit
transactions): 'INSERT INTO integers SELECT * FROM integers'
On a certain iteration, the query from item 3 hangs at least for 10 minutes
(probably, it actually hangs forever). This is because HeapLockManager by
default has a limited number of slots (by default, it's 1024 * 1024 ~ 1M
slots). If there are too many locks taken at the same time, the slots are
exhausted and lock attempt fails. It seems that SQL just repeats a query in
such a case (at least, for implicit transactions), and there is no repeat limit.
As a result, if user's query takes too many locks, it might not succeed at all
(with given lock table size), but the actual reason ('too small lock table')
will not be communicated to the user. The query will simply hang forever, or,
if a statement/query/transaction timeout is used, a timeout will happen.
This seems to be a bad UX.
> Queries permanently causing lock table overflow get retried forever
> -------------------------------------------------------------------
>
> Key: IGNITE-24340
> URL: https://issues.apache.org/jira/browse/IGNITE-24340
> Project: Ignite
> Issue Type: Bug
> Reporter: Roman Puchkovskiy
> Priority: Major
> Labels: ignite-3
>
> Here is a scenario (requires implicit PKs):
> 1. CREATE TABLE integers(i INTEGER)
> 2. INSERT INTO integers VALUES (0), (0), (0), (0)
> 3. Repeat the following query a few times (without using explicit
> transactions): 'INSERT INTO integers SELECT * FROM integers'
>
> On a certain iteration, the query from item 3 hangs at least for 10 minutes
> (probably, it actually hangs forever). This is because HeapLockManager by
> default has a limited number of slots (by default, it's 1024 * 1024 ~ 1M
> slots). If there are too many locks taken at the same time, the slots are
> exhausted and lock attempt fails. It seems that SQL just repeats a query in
> such a case (at least, for implicit transactions), and there is no repeat
> limit.
> As a result, if user's query takes too many locks, it might not succeed at
> all (with given lock table size), but the actual reason ('too small lock
> table') will not be communicated to the user. The query will simply hang
> forever, or, if a statement/query/transaction timeout is used, a timeout will
> happen.
> This seems to be a bad UX.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
