[Bug]: Decompression doesn't handle visibility properly

[erimatnor]

What type of bug is this?

Incorrect result

What subsystems and features are affected?

Compression

What happened?

When decompressing a chunk, the chunk will appear empty to ongoing transactions that are using isolation level REPEATABLE READ.

When compressing a chunk, the data is frozen and visible to all transactions/snapshots, but when the chunk is decompressed, the data is written to the non-compressed relation as new data without transferring visibility information. At the same time, the compressed relation is removed in a non-MVCC safe way.

TimescaleDB version affected

2.14.2

PostgreSQL version used

16

What operating system did you use?

Ubuntu 23.10

What installation method did you use?

Source

What platform did you run on?

On prem/Self-hosted

Relevant log output and stack trace

postgres=# start transaction isolation level repeatable read;
START TRANSACTION
-- query a different table to initialize a snapshot
postgres=*# select * from hyper2;
          time          | device_id | location_id | temp 
------------------------+-----------+-------------+------
 2022-06-01 05:00:00+02 |         1 |           6 |    6
 2022-06-01 06:00:00+02 |         1 |           7 |    7
 2022-06-01 07:00:00+02 |         1 |           8 |    8
 2022-06-01 08:00:00+02 |         2 |           8 |    8
 2022-06-01 09:00:00+02 |         2 |           8 |    8
 2022-06-01 10:00:00+02 |         3 |           1 |    8
 2022-06-01 11:00:00+02 |         3 |           3 |    9
 2022-06-01 12:00:00+02 |         3 |           4 |   11
(8 rows)

-- other session decompressed a chunk in hyper so it appears empty for this session
postgres=*# select * from hyper;
 time | device_id | location_id | temp 
------+-----------+-------------+------
(0 rows)

postgres=*# commit;
COMMIT
-- after commit, hyper data is suddenly visible
postgres=# select * from hyper;
          time          | device_id | location_id | temp 
------------------------+-----------+-------------+------
 2022-06-01 07:00:00+02 |         1 |           8 |    8
 2022-06-01 08:00:00+02 |         2 |           8 |    8
 2022-06-01 09:00:00+02 |         2 |           8 |    8
 2022-06-01 10:00:00+02 |         3 |           1 |    8
 2022-06-01 11:00:00+02 |         3 |           3 |    9
 2022-06-01 12:00:00+02 |         3 |           4 |   11
(6 rows)

How can we reproduce the bug?

1. Start a transaction in repeatable read
2. Make sure to query at least one "other" table that won't be decompressed in order to initialize a snapshot
3. In another session/backend decompress a chunk
4. Query the chunk in the session running repeatable read