zabbix 7 with timescaledb not compressing.

[tonitsh]

Hello. I am running zabbix with postgres 14 + timescaledb 2.13.1
I have an issue. I noticed my db size growing significantly and when i check timescaledb_information.jobs i see the jobs, but next_start and initial_start values are empty. The rest of the data seems to be present.
in UI i see housekeeper compression is enabled and compress records older than 14d is present.
How do i initiate the first run for the compression policies ? in zabbix server config file the housekeeper settings are not set up, but in UI they are present.

a bit of background information with examples of my stupidity:
i upgraded from zabbix 6.0 to 7.0
timescaledb was something i did not know about - i recently took over this system.
So naturally i messed up. while upgrading i read that my timescaled (at that time) was too old 2.11 i think. so i updated it.
this is where my fun week began. i updated it to latest version. which was then 2.16 - which was unsupported. Rolling back was no longer an option, so i restored the old state (always fun restoring timescaled database - i ended up reimporting arount 4bln csv values), upgraded timescaledb to 2.13, did the upgrade again.
running the timescale sql skript, informed me that all my hypertables were already hypertables and TimescaleDB is already installed, not changing configuration.
i probably missed some step somewhere due to sleep depravation - because otherwise it would be compressing on a regular bases.
In logs i only see housekeeper running and removing only error data, the rest is 0, but im guessing this is due to zabbix seeing my restored data as only 30 days old ( deletion time is 90 days)

[cyber]

check if your compression setting are in place "select * from timescaledb_information.compression_settings ;"

Thanks to this topic, I went to look at my test instance.. discovered that it has issues with compression.. Same as here.. hypertables present, but mess with jobs and compression policies.. I'll see how much I can do manually before just scrapping it and recreating from scratch..

[tonitsh]

have you had any luck ?
I removed the jobs, turned off housekeeper, kept it off for 2 cosecutive runs, turned it back on. It created new jobs ( proc schema changed from _timescaledb_internal to _timescaledb_funtions) i can manually call the job, and my last attempt was running over an hour, without compressing a single chunk.

[tonitsh]

https://docs.timescale.com/use-timescale/latest/compression/troubleshooting/

SELECT _timescaledb_functions.start_background_workers();

Basicly what was wrong in my case, was that backgroundworkers had stopped.

after starting them the jobs continued to run. hope it helpes others aswell...

[tonitsh]

seems i was too hasty.
most of the jobs are working as intended, but the 2 main jobs are still broken.
history and history_uint jobs run too long without any luck. In history_uint job i see within the job, it goes to read data from already (manually) compressed jobs, instead of dealing with uncompressed chunks. and history job - well im still unable to understand what it is doing, i see no actions in processes.
does anyone have any idea how the history job is set up, letting the houseceeper recreate it doesnt change that it tries to reorder the already compressed chunk data.

[tonitsh]

Ok so overall i resovled the issue with updating the timescaledb to 2.16 ( in the ocrrect order) and the nthe jobs started working again on theyr own.
Gl anyone having similar issue.