MV_BLOCKED_QUERIES

This view shows which queries are waiting, and what they are waiting for. It can be used to help debug unexpected waiting issues.

Column name

Description

node_id

ID of the node running the blocked query.

id

ID of the blocked query.

query_text

The text of the blocked query.

blocking_node_id

ID of the node that is running the blocking query.

blocking_id

ID of the blocking query.

blocking_type

Information on the type of block. It can have one of the following values:

  • internal transaction: The query is waiting on an internal background operation that is holding a lock. The background thread may not have a process ID and BLOCKING_ID may be NULL in this case.

  • user transaction row lock: The query is waiting on a row-level lock held by another user transaction, for example, when one transaction updates rows that another query needs to read or write.

  • user transaction table lock: The query is waiting on a table-level lock held by another user transaction.

  • ddl lock: The query is waiting on a DDL operation that holds a lock on a specific table, pipeline object, or at the database level.

  • plan compilation lock: The query is waiting for a query plan compilation to complete because the plan (or associated metadata) is currently locked by another compilation or garbage collection.

  • database cluster operation lock: The query is waiting on a cluster‑level operation, for example, REBALANCE PARTITIONS.

blocking_query_text

The text of the blocking query, or a description of the connection. For example: open idle transaction.

Example mv_blocked_queries Results

NODE_ID

ID

QUERY_TEXT

BLOCKING_NODE_ID

BLOCKING_ID

BLOCKING_TYPE

BLOCKING_QUERY_TEXT

1

42

insert into t values (1)

1

17

user transaction

open idle transaction

Both id and blocking_id refer to the id from information_schema.processlist. This means you can join information_schema.mv_blocked_queries with information_schema.processlist to get more detail about the blocked or blocking process.

Once you know the query or connection responsible for blocking, you can use KILLALL QUERIES or KILL CONNECTION and KILL QUERY to unblock your process.

Last modified: December 4, 2025

Was this article helpful?

Verification instructions

Note: You must install cosign to verify the authenticity of the SingleStore file.

Use the following steps to verify the authenticity of singlestoredb-server, singlestoredb-toolbox, singlestoredb-studio, and singlestore-client SingleStore files that have been downloaded.

You may perform the following steps on any computer that can run cosign, such as the main deployment host of the cluster.

  1. (Optional) Run the following command to view the associated signature files.

    curl undefined
  2. Download the signature file from the SingleStore release server.

    • Option 1: Click the Download Signature button next to the SingleStore file.

    • Option 2: Copy and paste the following URL into the address bar of your browser and save the signature file.

    • Option 3: Run the following command to download the signature file.

      curl -O undefined
  3. After the signature file has been downloaded, run the following command to verify the authenticity of the SingleStore file.

    echo -n undefined |
    cosign verify-blob --certificate-oidc-issuer https://oidc.eks.us-east-1.amazonaws.com/id/CCDCDBA1379A5596AB5B2E46DCA385BC \
    --certificate-identity https://kubernetes.io/namespaces/freya-production/serviceaccounts/job-worker \
    --bundle undefined \
    --new-bundle-format -
    Verified OK

Try Out This Notebook to See What’s Possible in SingleStore

Get access to other groundbreaking datasets and engage with our community for expert advice.