Enabling timescaleDB on existing database fills disk

[jjeff123]

I've read all about enabling timescale on an existing database, seems easy enough. But when I run the timescaledb.sql script as detailed in the documentation, it fills the disk and crashes.
Started with a 393GB disk containing a 320GB database, so about 50GB free. After roughly an hour, it had gobbled up the remaining space and crashed.


I just upgraded from 6.04 to 6.4.3, then installed timescale and ran the script.

user@servername:/usr/share/zabbix-sql-scripts/postgresql$ cat /usr/share/zabbix-sql-scripts/postgresql/timescaledb.sql | sudo -u zabbix psql zabbix
NOTICE: PostgreSQL version 13.11 (Debian 13.11-0+deb11u1) is valid
NOTICE: TimescaleDB extension is detected
NOTICE: TimescaleDB version 2.11.0 is valid
NOTICE: migrating data to chunks
DETAIL: Migration might take a while depending on the amount of data.

Last 2 lines repeat a few times

zabbix is stopped and I don't see any errors in the zabbix or postgres logs

So am I doing something wrong or is this a copy then delete type operation where I need a lot more free disk space?

[jjeff123]

Answering my own question for future people who have same problem.
YES, enabling timescaleDB will use more disk space before it uses less.

Start of the process my postgres 13 database was 307GB
During the last step while it processes the database, disk space grew to 393GB, so 28% db growth
After starting zabbix again, it spent perhaps an 30 minutes doing cleanup, during which things didn't appear to work well. I wasn't seeing any new data and my zabbix server queue (administration -> Queue) was enormous.
1 hour post timescale script, database usage is down to 255GB or a 17% savings. This is far below what the timescale article says I should be seeing, so I suspect things will get better over time.

[jjeff123]

My real database size problem was a bug, fixed in 6.06, related to the auditlog not being cleaned up. I've since fixed that and shrunk database to under 40GB