This section contains some ideas for troubleshooting common problems experienced with compression.

ERROR: cannot update/delete rows from chunk <CHUNK_NAME> as it is compressed

Compressed chunks of a continuous aggregate can't be refreshed. This follows from a general limitation where compressed chunks can't be updated or deleted.

If you receive historical data and must refresh a compressed region, first decompress the chunk. Then manually run refresh_continuous_aggregate.

Products:
ERROR: cannot add column with constraints or defaults to a hypertable that has compression enabled

If you attempt to add a column with constraints or defaults to a hypertable that has compression enabled, you might get this error. To add the column, you need to decompress the data in the hypertable, add the column, and then compress the data.

Products:
ERROR: must be owner of hypertable "HYPERTABLE_NAME"

If you attempt to compress or decompress a chunk with a non-privileged user account, you might get this error. To compress or decompress a chunk, your user account must have permissions that allow it to perform CREATE INDEX on the chunk. You can check the permissions of the current user with this command at the psql command prompt:

\dn+ <USERNAME>

To resolve this problem, grant your user account the appropriate privileges with this command:

GRANT PRIVILEGES
ON TABLE <TABLE_NAME>
TO <ROLE_TYPE>;

For more information about the GRANT command, see the PostgreSQL documentation.

Products:
ERROR: invalid attribute number -6 for _hyper_2_839_chunk
CONTEXT: SQL function "hypertable_local_size" statement 1 PL/pgSQL function hypertable_detailed_size(regclass) line 26 at RETURN QUERY SQL function "hypertable_size" statement 1
SQL state: XX000

You might see this error if your hypertable indexes have become very large. To resolve the problem, reindex your hypertables with this command:

reindex table _timescaledb_internal._hyper_2_1523284_chunk

For more information, see the hypertable documentation.

Products:

Your scheduled jobs might stop running for various reasons. On self-hosted TimescaleDB, you can fix this by restarting background workers:

SELECT _timescaledb_internal.start_background_workers();

On Timescale and Managed Service for TimescaleDB, restart background workers by doing one of the following:

  • Run SELECT timescaledb_pre_restore(), followed by SELECT timescaledb_post_restore().
  • Power the service off and on again. This might cause a downtime of a few minutes while the service restores from backup and replays the write-ahead log.
Products:

Keywords

Found an issue on this page?

Report an issue!