Troubleshoot Query Behavior

On this page Carat arrow pointing down
CockroachDB v2.0 is no longer supported. For more details, see the Release Support Policy.

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:

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.

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.

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=,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:

Yes No
On this page

Yes No