[Bug]: TimescaleDB chunk compression hangs that is causing table reads to hang

[Atul-Munde]

What type of bug is this?

Other

What subsystems and features are affected?

Compression, Query executor

What happened?

I am experiencing an issue with TimescaleDB chunk compression that is causing table reads to hang.

Problem Summary:

I am unable to compress the chunk for the period 2 November 2025 – 3 November 2025. Compression (both via policy and manual command) does not complete for this chunk.

Whenever I attempt compression for this specific chunk, all reads on the hypertable hang, and the table becomes unresponsive until compression is cancelled.

There are no related errors or messages in the logs, only the hanging behaviour.

Context:

My TimescaleDB hypertable originally used a 7-day chunk interval (previous chunks compressed successfully).
After switching to a 1-day chunk interval, compression has worked for all other chunks—before and after this problematic one.

2 Nov – 3 Nov is the only chunk that cannot be compressed and causes the table to hang during attempts.
Example chunk structure and status (all other chunks compressed and healthy):

15 Oct – 22 Oct: Compressed
22 Oct – 29 Oct: Compressed
29 Oct – 31 Oct: Compressed
31 Oct – 2 Nov: Compressed
2 Nov – 3 Nov: Not Compressed, hangs on compression
3 Nov – 6 Nov: Compressed
6 Nov – 7 Nov: Compressed
7 Nov – 8 Nov and onward: All 1-day chunks, compressed

Question:

1. Why might this specific chunk (2 Nov – 3 Nov) hang on compression and block all reads on the hypertable?
2. Are there known issues or troubleshooting steps for this scenario?
3. How can I resolve or safely compress this chunk without impacting reads?

Environment:
TimescaleDB version: 16.3
PostgreSQL version: 2.15.2

TimescaleDB version affected

2.15.2

PostgreSQL version used

16.3

What operating system did you use?

6.12.58-82.121.amzn2023.x86_64

What installation method did you use?

Docker

What platform did you run on?

Amazon Web Services (AWS)

Relevant log output and stack trace

How can we reproduce the bug?

Create a standard PostgreSQL table and convert it into a hypertable using an initial chunk_time_interval.
Populate the table with enough data to generate several chunks. At this stage, ensure the data is uncompressed.
Change the interval to a different value, such as 1 day. It is important to note that modifying the interval does not change existing chunks; it only applies to newly created ones.
Insert a small amount of data (e.g., 0.2 GB as seen in your case) that falls exactly on the boundary where the interval was changed
Apply a compression policy to the hypertable or manually trigger the compression job
The Resulting Bug Behaviour
If successfully reproduced, you will observe the following:
• Indefinite Stalling: The policy_compression job or manual compress_chunk command will run indefinitely (often reported as stuck for 40+ minutes)
 Heavy Locking: The compression process will hold a lock on the hypertable, which blocks all reads, effectively stopping the database from processing other traffic

[philon123]

We occasionally face the same issue.. in our case, manually decompressing and then compressing the chunk again works.

[antekresic]

I've given a shot at reproducing this issue but with no luck.

The version you are using is quite a bit old, I would definitely try to upgrade if possible. There have been significant efforts to improve the locking behavior and overall performance improvements that could have remedied this issue.

If that isn't an option, it would be most beneficial if you could generate a sql script to reproduce this issue on version 2.15.2. If we could get that, at least we can check if the issue exists on the latest versions. It would help us a lot.

Thanks,