timescaledb icon indicating copy to clipboard operation
timescaledb copied to clipboard

No sensible upgrade path from oss to community edition

Open minfrin opened this issue 4 years ago • 10 comments

Relevant system information:

  • OS: CentOS8
  • PostgreSQL version: 12
  • TimescaleDB version (output of \dx in psql): 1.7.1
  • Installation method: dnf

Describe the bug There does not appear to be a sensible upgrade path from timescaledb OSS as supplied by Postgres and timescaledb community.

To Reproduce Steps to reproduce the behavior:

  1. Install postgresql 12 and timescaledb_12 from postgresql repo
  2. Apply timescaledb repo as per docs at https://docs.timescale.com/latest/getting-started/installation/rhel-centos/installation-yum
  3. Install timescaledb-postgresql-12 from timescaledb repo

Expected behavior Expected timescaledb-postgresql-12 to replace timescaledb_12.

Actual behavior Instead, both timescaledb_12 and timescaledb-postgresql-12 sit side by side on the machine. There is no obvious way to tell postgresql which one to use, as docs for configuring both are identical. Removing the OSS edition causes postgresql to refuse to start. No obvious path to follow at this point.

minfrin avatar May 29 '20 13:05 minfrin

Looks like there is also no sensible upgrade path from the OSS edition to the enterprise edition either.

The docs at https://docs.timescale.com/latest/getting-started/exploring-enterprise say:

WARNING:If you explicitly built or downloaded an Apache 2.0 binary, you will not be able to directly activate TimescaleDB Enterprise. You must upgrade to a Timescale-Licensed binary first.

There is no link to any docs telling you how to upgrade.

minfrin avatar May 29 '20 13:05 minfrin

Some experimentation shows that the attempt to install timescaledb-postgresql-12 skips the linking of timescaledb into the postgres extensions folder, leaving dead code installed on the machine.

It seems there is no current upgrade path, you have to physically uninstall the OSS timescaledb, and then separately install the community timescaledb to get the install to do anything.

minfrin avatar May 29 '20 13:05 minfrin

Hi @minfrin Typically migrations happens across versions, not between the same version. (And it looks like you currently have software that was built by a third party, as opposed to us.)

Are you running 1.7.1 of the version from the PG repos?

mfreed avatar May 29 '20 13:05 mfreed

The third party is postgresql themselves, who provide the OSS timescaledb in their repo.

Because your repo depends on postgresql's repo, it means you have two conflicting copies of timescaledb in the same repo space.

Following the RPM convention, when your timescaledb package is installed, it should move any existing /usr/pgsql-12/share/extension/timescaledb.control file out of the way as timescaledb.control.rpmsave, and put it back it you uninstall.

minfrin avatar May 29 '20 13:05 minfrin

Thanks for the suggestion. Can you clarify the version, though?

mfreed avatar May 29 '20 14:05 mfreed

Version in the postgresql repo is this one:

[root@monitor ~]# dnf install timescaledb_12
timescale_timescaledb                                                                                                                     132  B/s | 833  B     00:06    
Dependencies resolved.
==========================================================================================================================================================================
 Package                                      Architecture                         Version                                     Repository                            Size
==========================================================================================================================================================================
Installing:
 timescaledb_12                               x86_64                               1.7.0-1.rhel8                               pgdg12                               231 k

Transaction Summary
==========================================================================================================================================================================
Install  1 Package

minfrin avatar May 29 '20 15:05 minfrin

This is your RPM:

[root@monitor ~]# rpm -q -i timescaledb-postgresql-12-1.7.1-0.el8.x86_64
Name        : timescaledb-postgresql-12
Version     : 1.7.1
Release     : 0.el8
Architecture: x86_64
Install Date: Fri 29 May 2020 15:51:39 SAST
Group       : Unspecified
Size        : 5925600
License     : Apache-2.0 and Timescale License
Signature   : (none)
Source RPM  : timescaledb-postgresql-12-1.7.1-0.el8.src.rpm
Build Date  : Tue 19 May 2020 22:23:30 SAST
Build Host  : 3d22b39910a0
Relocations : (not relocatable)
URL         : https://www.timescale.com
Summary     : An open-source time-series database packaged as a PostgreSQL extension.
Description :
An open-source time-series database optimized for fast ingest and complex queries. Engineered up from PostgreSQL, packaged as an extension.

minfrin avatar May 29 '20 15:05 minfrin

Same problem on Fedora. I just discovered that some functions are unavailable because I have the "Apache license" version installed. NO clear way to install the TSL version.

Separately, but related: We are running Fedora 32. Installed standard postgres using dnf. When I attempted to install the package "timescaledb-postgresql-12.x86_64", it errors saying, "nothing provides postgresql12". However our version of postgres is 12.4

noahsilverman avatar Oct 02 '20 04:10 noahsilverman

I have same issue when running Postgres 12 with Timescaledb extention. Both are install from Fedora 31 official repo. Workaround by installing Timescaledb from source not success with incompatible *.so library error. Doesn't have time to try installing both Postgres 12 and Timescaledb from source.

HarryHuy avatar Oct 15 '20 07:10 HarryHuy

Hi all @minfrin @noahsilverman @HarryHuy, do you think you might be able to check if this is still the case with the latest version of timescaledb? Will try to reproduce this as well.

konskov avatar Jun 14 '22 12:06 konskov

Dear Author,

This issue has been automatically marked as stale due to lack of activity. With only the issue description that is currently provided, we do not have enough information to take action. If you have or find the answers we would need, please reach out. Otherwise, this issue will be closed in 30 days. Thank you!

github-actions[bot] avatar Sep 26 '22 02:09 github-actions[bot]

Dear Author,

We are closing this issue due to lack of activity. Feel free to add a comment to this issue if you can provide more information and we will re-open it. Thank you!

github-actions[bot] avatar Oct 27 '22 02:10 github-actions[bot]

Hi there team,

I can confirm this is still the case in Fedora 39. I've been attempting to find a way to do this for a few days, and no luck. I just posted on the forums about it by any direction that might get me to a working install would be great.

https://www.timescale.com/forum/t/fedora-39-halp/2307

theashguy avatar Nov 17 '23 11:11 theashguy