You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Roman Puchkovskiy (Jira)" <ji...@apache.org> on 2025/01/29 10:22:00 UTC
[jira] [Updated] (IGNITE-24340) Queries permanently causing lock table overflow get retried forever
[ 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)