TimescaleDB compression error: invalid time argument type "bigint"

[LordBass]

Hello.

I'm migrating my zabbix instance to TimescaleDB. Everything going very well so far, but when using Zabbix 5.4.7 + TimescableDB 2.5.0 and enabling compression, all compression tasks fail with:

2021-10-29 18:14:27.247 UTC [10576] LOG: job 1012 threw an error
2021-10-29 18:14:27.247 UTC [10576] ERROR: invalid time argument type "bigint"
2021-10-29 18:14:27.247 UTC [10576] HINT: Try casting the argument to "integer".
2021-10-29 18:14:27.247 UTC [10576] CONTEXT: PL/pgSQL function _timescaledb_internal.policy_compression_integer(i nteger,integer,bigint,integer,boolean,boolean) line 17 at FOR over SELECT rows
SQL statement "CALL _timescaledb_internal.policy_compression_integer(
job_id, htid, lag_integer,
maxchunks, verbose_log, recompress_enabled )"
PL/pgSQL function _timescaledb_internal.policy_compression(integer,j sonb) line 62 at CALL
2021-10-29 18:14:27.249 UTC [1] LOG: background worker "Compression Policy [1012]" (PID 10576) exited with exit code 1

I've validated that my schema is in sync with the schema in zabbix-sql-scripts.

Setup information:
zabbix-server-pgsql 5.4.7-1+debian10 (installed via debian packages)
postgresql 12.8 (timescaledb 2.5.0) installed via docker (timescale/timescaledb:latest-pg12)

Should I file a bug report?

[Adm20]

This is not an answer to the question, but I'll just say that today I updated Zabbix to version 5.4.7 (from 5.4.6), and TimeScaleDB to 2.5.0 (from 2.4.1). Server OS - Centos 8 Stream. Compression is enabled in the settings, there are no errors in the logs.

[LordBass]

Adm20 did you check your postgres logs? Are you using postgres 12 as well?

[Adm20]

Now I have this error in the PSQL logs. Yes, PSQL version 12.

[LordBass]

Good to know! Compression isn't working on TimescaleDB 2.5.0, then. I'll open an issue

[Adm20]

I found that the issue is already on the timescaledb github: https://giters.com/timescale/timescaledb/issues/3773
Now I am trying to figure out how to apply a temporary fix

Update: I still did not understand how to apply the fix, I just rolled back to friday's backup. Let's wait for the new version of TimeScaleDB without this bug.

[splitek]

I wonder... if we turn off compression then error will be gone or not?
Couple days ago I upgraded old TSDB 1.7.4 to 2.5.0 on Zabbix 5.0.17 on my test environment I have no errors but I'm not using compression.

[LordBass]

If you turn off compression those errors don't show up at all, so you should be safe