Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#74668 - [promscale_extension] PostgreSQL cannot be upgraded

Attached to Project: Community Packages
Opened by Andrej Podzimek (andrej) - Saturday, 07 May 2022, 00:52 GMT
Last edited by George Rawlinson (rawlinsong) - Sunday, 19 June 2022, 19:02 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To George Rawlinson (rawlinsong)
Architecture All
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


This turns a routine pg_upgrade into a total disaster. My server is down. So much for a description.

Just in case you are considering the following (== symlinking of missing PostgreSQL 14 extensions into the PostgreSQL 13 directory):

# cd /opt/pgsql-13/share/extension
# for f in /usr/share/postgresql/extension/*; do if ! [[ -f "${f##*/}" ]]; then sudo ln -s "$f" "${f##*/}"; fi; done

No, this^^^ does *not* work or change anything. The error message is still the same.

Additional info:

* package version(s)
postgresql 14.2-1
postgresql-old-upgrade 13.6-1
promscale 0.10.0-1
promscale_extension 0.3.2-2 << This has no "-old-upgrade" counterpart, which is quite likely the root cause.

* config and/or log files etc.

command: "/opt/pgsql-13/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/var/lib/postgres/olddata" -o "-p 50432 -b -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directories='/var/lib/postgres/tmp'" start >> "pg_upgrade_server.log" 2>&1
waiting for server to start....2022-05-07 02:03:03.802 CEST [946810] FATAL: could not access file "promscale": No such file or directory
2022-05-07 02:03:03.802 CEST [946810] LOG: database system is shut down
stopped waiting
pg_ctl: could not start server

* link to upstream bug report, if any

There is no such bug report, most likely because Promscale expects PostgreSQL clusters to be just throwaway / expendable instances that nobody cares about.

Sadly, I made the mistake of sharing a single PostgreSQL instance between Promscale and my other databases. Because PostgreSQL is a mature multi-user database … or is it not?! Well, it *is*, unless bad extensions are involved. :-/

This will never happen again, because this is the last time I’ve EVER used Promscale. Not worth it.

For the record: Use the default storage that Prometheus provides. Seriously. It is more than appropriate. It just works. Store it on a distributed file system if need be. Bad PostgreSQL extensions are simply NOT worth it. Prometheus beats Promscale, any time, in any setup.

Steps to reproduce:
Just don’t. Don’t reproduce this. Downtime awaits you. Wait until this is fixed. Or, ideally, avoid Promscale. It’s simply not worth it.
This task depends upon

Closed by  George Rawlinson (rawlinsong)
Sunday, 19 June 2022, 19:02 GMT
Reason for closing:  Won't fix
Additional comments about closing:  promscale packages no longer in repositories
Comment by George Rawlinson (rawlinsong) - Friday, 20 May 2022, 00:29 GMT
The extension linked against PG13 needs to be symlinked into the /opt/pg-13 dir. This is somewhat described on the wiki page & upstream documentation.

There isn't a promscale/timescale old upgrade package yet.