Timescaledb: Upgrade to timescaleDB 2.0 failed ("shared library version mismatch")

[AlexFavre]

Relevant system information:

• OS: RHEL 7.8
• PostgreSQL version (output of postgres --version): psql (PostgreSQL) 12.5
• TimescaleDB version (output of \dx in psql): 1.7.4
• Installation method: [e.g., "using Docker", "apt install", "source"]: yum

We use patroni for clustering postgres with 2 members on learder and one replica
patroni 2.0.1

Describe the bug
When we try to upgrade, it's failed with this message:

ERROR: extension "timescaledb" version mismatch: shared library version 2.0.0; SQL version 1.7.4
CONTEXT: parallel worker
SQL statement "SELECT sum(_ts_meta_count), count(*) FROM _timescaledb_internal.compress_hyper_8_489_chunk"
PL/pgSQL function inline_code_block line 21 at EXECUTE

To Reproduce
Steps to reproduce the behavior:
1- Install timescaledb RPM for 2.0 yum install timescaledb-2-postgresql-12.x86_64
2 - psql -X zabbix
3- ALTER EXTENSION timescaledb UPDATE;
4 - ERROR: extension "timescaledb" version mismatch: shared library version 2.0.0; SQL version 1.7.4
CONTEXT: parallel worker
SQL statement "SELECT sum(_ts_meta_count), count(*) FROM _timescaledb_internal.compress_hyper_8_489_chunk"
PL/pgSQL function inline_code_block line 21 at EXECUTE

Thanks in advance for your help

[Da-Teach]

I had the same issue, you have to (temporarily) set max_parallel_workers to 0. After upgrade you can revert it back to original value.

[AlexFavre]

It's ok now.
thanks a lot

[mfreed]

So you were getting that error about the SELECT when you try to run ALTER EXTENSION as the first thing in a new psql context? Is this anything having to do with zabbix running jobs concurrently in the background? (I admit we should figure out how to solve it, just curious where that command is coming from?)

Thanks!

[AlexFavre]

Yes, first command was always 'ALTER EXTENSION timescaledb UPDATE;' in new psql session connect with 'psql -X zabbix'.

change parallel_max_worker = 0 in file
reload by patroni each node
connect with psql -X zabbix
apply ALTER EXTENSION timescaledb UPDATE;
it's ok

[biggerfisch]

I get this issue while using docker in a DB that has never seen Zabbix and has no other services running.

Details edit:

• Have compression on
• old container tag: timescale/timescaledb:1.7.4-pg11
• new container tag: timescale/timescaledb:2.0.0-pg11

Have not tried a full reproduction chain, but I imagine it would follow a path of something like: installation, enabling compression, letting that run, then attempting the upgrade.

[slasktrat]

Had same issue and this solved it, thanks.

[dwalthour]

This issue also solved it for me, but the symptoms of upgrading while max_parallel_workers > 0 were very very different. For me the upgrade process ran for 24-36 hours and then failed with no clue why. When I set max_parallel_workers = 0 in the config file (suggested by Mike, thanks!), then the same update took less than a minute and completed successfully. I strongly recommend that you suggest in your documentation that people upgrading timescale set max_parallel_workers = 0 before doing the upgrade!