The page provides information on all transactions which are holding and/or requesting locks on worker node tables only, and the locks they hold and/or are requesting.
Where this page operates at the cluster level, information is not available about schemas or users, or about leader node tables (such as the system tables). You’re lucky I can find out the database name! =-)
All you get are locks on normal Redshift tables, and as such, you will not see the locks this query itself generates on the system tables it uses.
The main use for this page I think is to order locks by duration, and then look askance at anything which is unduly long-lived.
| Name | Type |
|---|---|
| database_id | int8 |
| database | varchar |
| table_id | int8 |
| table | varchar |
| transaction:pid | int4 |
| transaction:xid | int8 |
| transaction:start | timestamp |
| transaction:duration | interval |
| lock:type | varchar |
| lock:state | varchar |
The database ID. This column is emitted in CSV exports only.
The database name.
The table ID. This column is emitted in CSV exports only.
Surprisingly, table IDs turn out to be unique across all databases.
The table name.
Note that in stv_tbl_perm, the maximum length of a table
name is 72 bytes, which is less than the actual maximum of 127 bytes. As
such, names over 72 bytes will be truncated.
The process ID.
When a user connects to the cluster, a process is spawned, which accepts that connection. That’s the process the ID is for. That process is also the process which issues queries, and when you need to cancel a query, you in fact cancel the process, which by being cancelled, inherently also cancels the query it is running.
The transaction ID.
Transaction start timestamp.
Transaction duration.
| Lock Type | Description |
|---|---|
| AccessExclusiveLock | Blocks AccessShareLock and ShareRowExclusiveLock locks |
| AccessShareLock | Blocks AccessExclusiveLock locks |
| ShareRowExclusiveLock | Blocks other ShareRowExclusiveLock locks |
Set to held or pending.