If a query returns an unexpected result or takes longer than expected to process, this page will help you troubleshoot the issue.
Correctness Issues
If your queries return unexpected results, there are several possibilities:
- You’ve encountered a known limitation, UX surprise or other problem with SQL semantics. Feel free to leave a comment on the existing issue indicating that you’ve encountered a problem as well.
- Your application has a bug. It's always worthwhile to check and double-check your application’s logic before filing an issue. That said, you can always reach out for support.
- CockroachDB has a bug. Please file an issue.
Performance Issues
If queries are taking longer than expected to process, there are a few things you can check into:
Review your deployment's monitoring. General network latency or partitioning events can affect query response times.
If you're still unable to determine why the query executes slowly, please file an issue.
bad connection & closed Responses
If you receive a response of bad connection or closed, this normally indicates that the node you connected to died. You can check this by connecting to another node in the cluster and running cockroach node status.
Once you find the downed node, you can check its logs (stored in cockroach-data/logs by default).
Because this kind of behavior is entirely unexpected, you should file an issue.
SQL Logging
There are several ways to log SQL queries. The type of logging you use will depend on your requirements.
- For per-table audit logs, turn on SQL audit logs.
- For system troubleshooting and performance optimization, turn on cluster-wide execution logs.
- For local testing, turn on per-node execution logs.
SQL audit logs
This is an experimental feature. The interface and output are subject to change.
SQL audit logging is useful if you want to log all queries that are run against specific tables.
For a tutorial, see SQL Audit Logging.
For SQL reference documentation, see
ALTER TABLE ... EXPERIMENTAL_AUDIT.
Cluster-wide execution logs
For production clusters, the best way to log all queries is to turn on the cluster-wide setting sql.trace.log_statement_execute:
> SET CLUSTER SETTING sql.trace.log_statement_execute = true;
With this setting on, each node of the cluster writes all SQL queries it executes to its log file. When you no longer need to log queries, you can turn the setting back off:
> SET CLUSTER SETTING sql.trace.log_statement_execute = false;
Per-node execution logs
Alternatively, if you are testing CockroachDB locally and want to log queries executed just by a specific node, you can either pass a CLI flag at node startup, or execute a SQL function on a running node.
Using the CLI to start a new node, pass the --vmodule flag to the cockroach start command. For example, to start a single node locally and log all SQL queries it executes, you'd run:
$ cockroach start --insecure --host=localhost --vmodule=exec_log=2
From the SQL prompt on a running node, execute the crdb_internal.set_vmodule() function:
> SELECT crdb_internal.set_vmodule('exec_log=2');
This will result in the following output:
+---------------------------+
| crdb_internal.set_vmodule |
+---------------------------+
| 0 |
+---------------------------+
(1 row)
Once the logging is enabled, all of the node's queries will be written to the CockroachDB log file as follows:
I180402 19:12:28.112957 394661 sql/exec_log.go:173 [n1,client=127.0.0.1:50155,user=root] exec "psql" {} "SELECT version()" {} 0.795 1 ""
Something Else?
Try searching the rest of our docs for answers or using our other support resources, including:
Was this helpful?
