This topic describes how to diagnose issues related to queries and manage queries on a Hologres instance.
Overview
Hologres is compatible with PostgreSQL. You can view the execution information about queries on a Hologres instance by querying the hg_stat_activity (pg_stat_activity) view. This helps you analyze query execution information and diagnose the related issues. The query management feature involves the following operations:
View active queries by using SQL statements: View the runtime information about SQL statements to better manage SQL statements.
Use HoloWeb to view and manage active queries in a visualized way: Use HoloWeb to view and manage active queries in a visualized way.
Troubleshoot lock issues: Check whether an SQL statement of an active query acquires a lock or is waiting for a lock to be released.
Cancel queries: Cancel a query that does not meet expectations by executing statements.
Change the timeout period of active queries: Change the timeout period of active queries to prevent deadlocks.
Change the timeout period of idle queries: Change the timeout period of idle queries to prevent deadlocks.
Query slow query logs: Query slow query logs to diagnose, analyze, and optimize slow queries or failed queries.
FAQ: Resolve the issue if the error message
ERROR: canceling statement due to statement timeout
is reported.
Query the hg_stat_activity (pg_stat_activity) view
In Hologres V2.0 and later, the pg_stat_activity view is upgraded to the hg_stat_activity view. The hg_stat_activity view is an extension of the pg_stat_activity view. You can use the hg_stat_activity view to query more detailed runtime information about active SQL queries. For example, you can query the query ID
, query engine
, and resource consumption information. This helps you diagnose issues of active queries. You can execute the following statements to query the runtime information about SQL queries on a Hologres instance. You can also use other management tools that are compatible with PostgreSQL to query the runtime information about SQL queries based on the pg_stat_activity view.
-- Recommended syntax for Hologres V2.0 and later
SELECT * FROM hg_stat_activity;
-- Syntax for Hologres V1.3 and earlier
SELECT * FROM pg_stat_activity;
The following table describes fields in the hg_stat_activity view.
Field | Description | Supported by the hg_stat_activity view | Supported by the pg_stat_activity view |
datid | The object identifier (OID) of the connected database at the Hologres backend. | Supported | Supported |
datname | The name of the connected database at the Hologres backend. | Supported | Supported |
pid | The ID of the process at the Hologres backend. | Supported | Supported |
query_id | The ID of the current SQL statement. One SQL statement corresponds to one query_id. | Supported | Not supported |
transaction_id | The ID of the transaction to which the current SQL statement belongs. A transaction may contain multiple SQL statements. | Supported | Not supported |
usesysid | The system identifier of the user in the current active session. | Supported | Supported |
usename | The username that is used to create the current connection. | Supported | Supported |
application_name | The type of the application on the client. Common application types:
For other applications, we recommend that you explicitly specify the | Supported | Supported |
running_info | The status of an SQL query during the query execution process. The value is in the JSON format. This field contains the following subfields:
| Supported | Not supported |
extend_info | Extended information such as the resource consumption during the SQL query execution. The value is in the JSON format. This field contains the following subfields:
Note The be_lock_waiters and be_lock_converting_waiters subfields are valid for the backend lock, not the frontend lock. For more information about how to troubleshoot lock issues, see Locks and lock troubleshooting. | Supported | Not supported |
state | The status of the connection. Valid values:
| Supported | Supported |
query_start | The time when the SQL query starts to be executed. If the value of state for the current SQL query is not active, the start time of the previous SQL query is used. | Supported | Supported |
client_addr | The IP address of the client. The displayed IP address may have been resolved and may not be the actual IP address of the client. | Supported | Supported |
client_hostname | The hostname of the client. | Supported | Supported |
client_port | The port number of the client. | Supported | Supported |
backend_start | The start time of the backend process. You do not need to pay much attention to this field of Hologres. | Supported | Supported |
xact_start | The start time of the current transaction of the process.
You do not need to pay much attention to this field of Hologres. | Supported | Supported |
state_change | The time when the state of the connection was last changed. You do not need to pay much attention to this field of Hologres. | Supported | Supported |
wait_event_type | The type of the event for which the backend is waiting for. If the backend is waiting for no event, the value of this field is NULL. Valid values:
| Supported | Supported |
wait_event | The name of the event for which the backend is waiting. If the backend is waiting for no event, the value of this field is NULL. | Supported | Supported |
backend_xid | The identifier of the top-level transaction at the Hologres backend. | Supported | Supported |
backend_xmin | The xmin scope at the backend. | Supported | Supported |
query | The last query that was run at the backend. If the value of the state field is | Supported | Supported |
backend_type | The type of the backend. Supported types include autovacuum launcher, autovacuum worker, logical replication launcher, logical replication worker, parallel worker, background writer, client backend, checkpointer, startup, walreceiver, walsender, and walwriter. Backend execution components such as PQE are also supported. Note Take note of the | Supported | Supported |
View active queries by using SQL statements
This section describes how to view active queries by using SQL statements.
View the current active query and the execution stage and resource consumption of the current active query.
NoteSuperusers of a Hologres instance can query the execution information about SQL statements that are submitted by all users of the Hologres instance. RAM users can query the execution information about SQL statements that are submitted only by themselves.
-- Syntax for Hologres V2.0 and later SELECT query,state,query_id,transaction_id,running_info, extend_info FROM hg_stat_activity WHERE state = 'active' AND backend_type = 'client backend' AND application_name != 'hologres' -- Syntax for Hologres V1.3 and earlier SELECT query,state,pid FROM pg_stat_activity WHERE state = 'active' AND backend_type = 'client backend' AND application_name != 'hologres'
The following result is returned:
------------------------------------------------------------------------------- query | insert into test_hg_stat_activity select i, (i % 7) :: text, (i % 1007) from generate_series(1, 10000000)i; state | active query_id | 100713xxxx transaction_id | 100713xxxx running_info | {"current_stage" : {"stage_duration_ms" :5994, "stage_name" :"EXECUTE" }, "engine_type" :"{HQE,PQE}", "fe_id" :1, "warehouse_id" :0 } extend_info | {"affected_rows" :9510912, "scanned_rows" :9527296 }
View running queries that are sorted based on the CPU utilization.
-- Syntax for Hologres V2.0 and later SELECT query,((extend_info::json)->'total_cpu_max_time_ms')::text::bigint AS cpu_cost,state,query_id,transaction_id FROM hg_stat_activity WHERE state = 'active' ORDER BY 2 DESC;
The following result is returned:
--------------------------------------------------------------------------------- query | select xxxxx cpu_cost | 523461 state | active query_id | 10053xxxx transaction_id | 10053xxxx --------------------------------------------------------------------------------- query | insert xxxx cpu_cost | 4817 state | active query_id | 1008305xxx transaction_id | 1008305xxx
View running queries that are sorted based on the memory usage.
-- Syntax for Hologres V2.0 and later SELECT query,((extend_info::json)->'total_mem_max_bytes')::text::bigint AS mem_max_cost,state,query_id,transaction_id FROM hg_stat_activity WHERE state = 'active' ORDER BY 2 DESC;
The following result is returned:
--------------------------------------------------------------------------------- query | update xxxx; mem_max_cost | 5727634542 state | active query_id | 10053302784827629 transaction_id | 10053302784827629 --------------------------------------------------------------------------------- query | select xxxx; mem_max_cost | 19535640 state | active query_id | 10083259096119559 transaction_id | 10083259096119559
View queries that are running on the current instance and take a long period of time.
-- Syntax for Hologres V2.0 and later SELECT current_timestamp - query_start AS runtime, datname::text, usename, query, query_id FROM hg_stat_activity WHERE state != 'idle' AND backend_type = 'client backend' AND application_name != 'hologres' ORDER BY 1 DESC; -- Syntax for Hologres V1.3 and earlier SELECT current_timestamp - query_start AS runtime, datname::text, usename, query, pid FROM pg_stat_activity WHERE state != 'idle' AND backend_type = 'client backend' AND application_name != 'hologres' ORDER BY 1 DESC;
The following result is returned:
runtime | datname | usename | query_id | current_query -----------------+----------------+----------+------------------------------------ 00:00:24.258388 | holotest | 123xxx | 1267xx | UPDATE xxx; 00:00:1.186394 | testdb | 156xx | 1783xx | select xxxx;
The result indicates that the UPDATE query takes a long period of time and has been running for 24 seconds.
Use HoloWeb to view and manage active queries in a visualized way
This section describes how to use HoloWeb to view and manage active queries in a visualized way.
Log on to the HoloWeb console. For more information, see Connect to HoloWeb and perform queries.
In the top navigation bar, click Diagnostics and Optimization.
In the left-side navigation pane, choose Management for Information about Active Queries > Active Query Tasks.
On the Active Query Tasks page, click Query to view and manage the active queries on the current instance.
The following table describes the parameters in the queried result.
Parameter
Description
Query Start
The time when the query starts to be executed.
Runtime
The period of time for which the query has been running.
PID
The process identifier (PID) of the query.
Query
The SQL statement that is executed to query data.
State
The status of the current connection. Valid values:
active: The connection is active.
idle: The connection is idle.
idle in transaction: The connection is idle in a long-running transaction.
idle in transaction (Aborted): The connection is idle in a failed transaction.
\N: This value indicates that the process is not a user connection process. In most cases, this state is returned for a maintenance process at the system backend and can be ignored.
User Name
The username that is used to create the current connection.
Application
The type of the application that initiates the query.
Client Address
The IP address of the client that sends the query request.
If a query does not complete after a long period of time, you can click Cancel in the Operation column to cancel the query. You can also select multiple queries and click Batch Cancel to cancel multiple queries at a time.
(Optional) Click Details in the Operation column of a query to view the details of the query.
On the Details page, you can perform the following operations:
Copy: Copy the SQL statement that is executed for the query.
Format: Format the SQL statement that is executed for the query.
Troubleshoot lock issues
You can check whether an SQL statement of active queries acquires a lock or is waiting for a lock to be released. For more information, see Locks and lock troubleshooting.
Cancel queries
This section describes how to cancel queries that do not meet expectations by executing statements.
Cancel a single query:
SELECT pg_cancel_backend(<pid>);
Cancel multiple queries at a time:
SELECT pg_cancel_backend(pid) ,query ,datname ,usename ,application_name ,client_addr ,client_port ,backend_start ,state FROM pg_stat_activity WHERE length(query) > 0 AND pid != pg_backend_pid() AND backend_type = 'client backend' AND application_name != 'hologres'
Change the timeout period of active queries
Hologres allows you to change the timeout period of active queries by executing an SQL statement.
Syntax
SET statement_timeout = <time>;
Parameters
time: the timeout period of active queries. Valid values: 0 to 2147483647. Default unit: milliseconds. If you want to append a unit to the specified time value, enclose the value and the unit in single quotation marks ('). Otherwise, an error message is returned. The current default timeout period is eight hours. The settings of the timeout period take effect only for queries in the current session.
NoteThe SET statement_timeout = <time> statement takes effect only when this statement is executed along with the SQL statements for which you want to change the timeout period.
Examples
Set the timeout period to 5,000 minutes. If you want to append a unit to the specified time value, enclose the value and the unit in single quotation marks (').
SET statement_timeout = '5000min' ; SELECT * FROM tablename;
Set the timeout period to 5,000 ms.
SET statement_timeout = 5000 ; SELECT * FROM tablename;
Change the timeout period of idle queries
The idle_in_transaction_session_timeout parameter specifies the timeout behavior after a transaction becomes idle. If you do not configure this parameter, a transaction that times out is not rolled back. As a result, deadlocks may occur during queries. Hologres allows you to change the timeout period of idle queries by executing an SQL statement.
Scenario
To prevent deadlocks during queries, you must specify the timeout period of idle queries. For example, the following code starts a transaction but does not commit it by using the
COMMIT
statement. This results in a transaction leak that eventually causes a database-level deadlock and affects the normal use of the database.BEGIN; SELECT * FROM t;
You can resolve the issue by configuring the idle_in_transaction_session_timeout parameter to specify the timeout period. If a transaction has not been committed or rolled back after its connection is idle for a period longer than the timeout period specified by the idle_in_transaction_session_timeout parameter, Hologres automatically rolls back the transaction and closes the connection.
Syntax
-- Change the timeout period for idle transactions in a session. SET idle_in_transaction_session_timeout=<time>; -- Change the timeout period for idle transactions in a database. ALTER database db_name SET idle_in_transaction_session_timeout=<time>;
Parameters
time: the timeout period of active queries. Valid values: 0 to 2147483647. Default unit: milliseconds. If you want to append a unit to the specified time value, enclose the value and unit in single quotation marks (' '). Otherwise, an error is returned. In Hologres V0.10 and earlier, the default value of this parameter is 0. This means that idle transactions are not automatically rolled back. In Hologres V1.1, the default value of this parameter is changed to 600000, which indicates 10 minutes. If a transaction is idle for more than 10 minutes, the transaction is rolled back.
NoteIf the timeout period is shorter than required, transactions that are in use may be rolled back by mistake. We recommend that you set an appropriate timeout period for idle transactions.
Examples
Set the timeout period to 300,000 ms.
-- Change the timeout period for idle transactions in a session. SET idle_in_transaction_session_timeout=300000; -- Change the timeout period for idle transactions in a database. ALTER database db_name SET idle_in_transaction_session_timeout=300000;
Query slow query logs
In Hologres V0.10 and later, you can query slow query logs. For more information, see Query and analyze slow query logs.
FAQ
Problem description
After SQL statements are executed, the following error message is returned:
ERROR: canceling statement due to statement timeout
.Possible causes and solutions
Cause 1: The timeout period is configured for a Hologres instance or a client in the following scenarios:
If you create an API in DataService Studio, the timeout period for DataService Studio is
10s
and cannot be modified. We recommend that you optimize SQL statements to reduce the execution time.If you execute a query by using a Hologres SQL node of HoloWeb or DataWorks, the timeout period for executing the query is
1 hour
and cannot be modified. We recommend that you optimize SQL statements to reduce the execution time.If a timeout period is configured for a Hologres instance, you can execute the following SQL statement to query the timeout period. If the error is caused by inappropriate setting of the timeout period, modify the timeout period.
SHOW statement_timeout;
If the timeout period is configured for a client or an application, you must check the settings of the client or the application. If the error is caused by the timeout period specified by the client, you can specify an appropriate timeout period based on your business requirements.
Cause 2: The DROP or TRUNCATE statement is executed on a table when DML statements are executed.
The execution of TRUNCATE is equal to the execution of both
DROP and CREATE
. When you execute the TRUNCATE statement, a table is dropped and created again. When DML statements are executed, row locks or table locks are acquired. For more information about locks, see Locks and lock troubleshooting. If the DROP or TRUNCATE statement is executed on the table at the same time, the DROP or TRUNCATE statement acquires the locks. In this case, the system cancels the DML statements. As a result, thestatement timeout
error message is returned.Solution: Use slow query logs to check whether the
DROP
orTRUNCATE
statement is executed on the table when DML statements are executed. The following sample code provides an example. We recommend that you do not execute the DROP or TRUNCATE statement when DML statements are executed.-- Query records of the DROP and TRUNCATE statements that are executed on a table in the previous day. SELECT * FROM hologres.hg_query_log WHERE command_tag IN ('DROP TABLE','TRUNCATE TABLE') AND query LIKE '%xxx%' AND query_start >= now() - interval '1 day';