Unable to compress chunks after update on TimescaleDB 2.18.2

Hello,
may I ask you for an advice how to resolve error with compressing chunks. It started after update to 18.2. on 27.3. (posgresql 15.12). I checked data in hypertables and their length is max 459 bytes. I also rebuild indexes for hypertable table, but seems there is problem with index created during compression of the chunks. I also considered to decompress whole hypertable, but this could be a problem due to space on filesystem - it is really big hypertable. Other hypertables are compressed normally without problem.

Could you please suggest steps how to troubleshoot.

2025-03-30 10:47:02.692 CEST [4049764-1] @ 67e90056.3dcb64 54000WARNING: compressing chunk “_timescaledb_internal._hyper_7_10048_chunk” failed when compression policy is executed
2025-03-30 10:47:02.692 CEST [4049764-2] @ 67e90056.3dcb64 54000DETAIL: Message: (index row size 5272 exceeds btree version 4 maximum 2704 for index “compress_hyper_8_10239_chunk_dbname__ts_meta_min_1__ts_meta_idx”), Detail: (Index row references tuple (588,35) in relation “compress_hyper_8_10239_chunk”.).
2025-03-30 10:47:02.692 CEST [4049764-3] @ 67e90056.3dcb64 54000CONTEXT: PL/pgSQL function _timescaledb_functions.policy_compression_execute(integer,integer,anyelement,integer,boolean,boolean,boolean,boolean) line 72 at RAISE
2025-03-30 10:59:16.985 CEST [4049764-4] @ 67e90056.3dcb64 54000WARNING: compressing chunk “_timescaledb_internal._hyper_7_10098_chunk” failed when compression policy is executed
2025-03-30 10:59:16.985 CEST [4049764-5] @ 67e90056.3dcb64 54000DETAIL: Message: (index row size 3488 exceeds btree version 4 maximum 2704 for index “compress_hyper_8_10240_chunk_dbname__ts_meta_min_1__ts_meta_idx”), Detail: (Index row references tuple (17,3) in relation “compress_hyper_8_10240_chunk”.).
2025-03-30 10:59:16.985 CEST [4049764-6] @ 67e90056.3dcb64 54000CONTEXT: PL/pgSQL function _timescaledb_functions.policy_compression_execute(integer,integer,anyelement,integer,boolean,boolean,boolean,boolean) line 72 at RAISE
2025-03-30 11:20:17.475 CEST [4049764-7] @ 67e90056.3dcb64 54000WARNING: compressing chunk “_timescaledb_internal._hyper_7_10145_chunk” failed when compression policy is executed
2025-03-30 11:20:17.475 CEST [4049764-8] @ 67e90056.3dcb64 54000DETAIL: Message: (index row size 5384 exceeds btree version 4 maximum 2704 for index “compress_hyper_8_10241_chunk_dbname__ts_meta_min_1__ts_meta_idx”), Detail: (Index row references tuple (663,47) in relation “compress_hyper_8_10241_chunk”.).
2025-03-30 11:20:17.475 CEST [4049764-9] @ 67e90056.3dcb64 54000CONTEXT: PL/pgSQL function _timescaledb_functions.policy_compression_execute(integer,integer,anyelement,integer,boolean,boolean,boolean,boolean) line 72 at RAISE
2025-03-30 11:20:17.512 CEST [4049764-10] @ 67e90056.3dcb64 00000LOG: job 1003 threw an error
2025-03-30 11:20:17.512 CEST [4049764-11] @ 67e90056.3dcb64 P0001ERROR: compression policy failure
2025-03-30 11:20:17.512 CEST [4049764-12] @ 67e90056.3dcb64 P0001DETAIL: Failed to compress ‘3’ chunks. Successfully compressed ‘1’ chunks.
2025-03-30 11:20:17.512 CEST [4049764-13] @ 67e90056.3dcb64 P0001CONTEXT: PL/pgSQL function _timescaledb_functions.policy_compression_execute(integer,integer,anyelement,integer,boolean,boolean,boolean,boolean) line 120 at RAISE

Hypertable belongs to pgwatch2.
CREATE TABLE IF NOT EXISTS public.stat_statements
(
“time” timestamp with time zone NOT NULL,
dbname text COLLATE pg_catalog.“default” NOT NULL,
data jsonb NOT NULL,
tag_data jsonb
)

Hello,
as a workaround I removed tag_data from order by:

ALTER TABLE stat_statements SET(timescaledb.orderby = ‘time DESC’);

option before was ‘time DESC, tag_data’

Can you suggest how to identify for example Index row references tuple (663,47)? compress_hyper_8_10241_chunk is dropped once failure occur.