[Bug]: Possible decompression lock firing on a SELECT statement, trying to understand why?

[SaulEthon]

What type of bug is this?

Locking issue

What subsystems and features are affected?

Compression

What happened?

Hi,

we are trying to figure out how to investigate this issue closer and where we can look at locks of timescale closer. We enabled compression and during testing everything seemed fine.

Some engineers are reporting strange behaviour during:

SELECT statements that shouldn't be taking long, they don't finish at all, it just locks up the db and we get no more logs from our backend during that operation.

We were under the assumptions that SELECT falls under DML that doesn't require decompression.

Is explain the right way to go about this? What timescale_meta_table will give me more info about this.

Thanks in advance.

TimescaleDB version affected

2.18.?

PostgreSQL version used

14

What operating system did you use?

Ubuntu

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?

--- Adding later, asking engineers now ---

[pnthao]

@SaulEthon It's really hard for us to guess what is going on without a reproducer. If a simple query on small amount of data is taking forever my first thought is that some concurrent session is holding a conflicting lock. You could check locks being hold by querying pg_locks