Description of problem: SELECT version(); reports: PostgreSQL 13.6 on x86_64-mageia-linux-gnu, compiled by gcc (Mageia 12.0.1-0.20220410.1.mga9) 12.0.1 20220410 (experimental), 64-bit $ postgres --version postgres (PostgreSQL) 13.6 Although: $ psql -V psql (PostgreSQL) 15.1 Version-Release number of selected component (if applicable): 15.1-1 How reproducible: always Steps to Reproduce: 1. 2. 3.
Thanks for the report; assigning it to ns80 who nurses PostgreSQL15.
Summary: /usr/bin/postgres 15.1 reports the wrong version => /usr/bin/postgres 15.1 reports the wrong version (13.6)Source RPM: (none) => postgresql15-15.1-1.mga9.src.rpmAssignee: bugsquad => nicolas.salguero
Something's wrong on that install. # psql -V psql (PostgreSQL) 13.9 I just installed postgresql13 on a Mageia 9 install that did not previously have any postgresql packages installed. # rpm -q -f /usr/bin/psql postgresql13-13.9-1.mga9
CC: (none) => davidwhodgins
(In reply to Pierre Fortin from comment #0) > Description of problem: SELECT version(); reports: PostgreSQL 13.6 on > x86_64-mageia-linux-gnu, compiled by gcc (Mageia 12.0.1-0.20220410.1.mga9) > 12.0.1 20220410 (experimental), 64-bit > > $ postgres --version > postgres (PostgreSQL) 13.6 > > Although: > $ psql -V > psql (PostgreSQL) 15.1 Hi, That bug and the two other ones (bug 31333 and bug 31341) seem to come from the fact that you have a mix between PostgreSQL 13 and 15. In my tests, if only packages postgresql15-* are installed, I cannot reproduce any of those bugs. Best regards, Nico.
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=31333, https://bugs.mageia.org/show_bug.cgi?id=31341
Created attachment 13621 [details] Installed packages May 10... This machine has only ever run Cauldron (mga9) since I received it. In May, I added this to my crontab: @daily (rpm -qa | sort > /home/ROOT/RPM.history/RPMS.`/bin/date +\%Y\%m\%d`) So I can provide the list of packages on this system for any day since May 10; or all if that would help. The attached file shows the packages installed on May 10,2022 and below are the current postgres packages: $ rpm -qa | grep postgres postgresql-jdbc-42.5.0-1.mga9 nextcloud-postgresql-24.0.5-3.mga9 postgresql15-15.1-1.mga9 postgresql15-plpgsql-15.1-1.mga9 postgresql15-plpython3-15.1-1.mga9 postgresql15-pltcl-15.1-1.mga9 postgresql15-plperl-15.1-1.mga9 postgresql15-pl-15.1-1.mga9 postgresql15-contrib-15.1-1.mga9 postgresql15-docs-15.1-1.mga9 lodevbasis7.6-postgresql-sdbc-7.6.0.0.alpha0-1 libgda5.0-postgres-5.2.10-4.mga9 To my knowledge, this machine has never had version 13 installed. Even if it did, due to being unable to get pgadmin4 to work; I only started using postgres around August, and 14 was the version at that time. To be correct, the attached package list does contain: postgresql13-docs-13.6-1.mga9 as the only clue that 13 may have been in the system (but never used) at that time. Even if 13 was installed before May 10; I've only done PG upgrade's via mcc. Any "mix" would have been a result of a Mageia provided update... HTH
Created attachment 13622 [details] Jan 6 installed packages Today's daily dump of installed packages shows no version 13... or 14... So I have no clue how to resolve these issues...
(In reply to Pierre Fortin from comment #4) > ....and below are > the current postgres packages: > > $ rpm -qa | grep postgres > postgresql-jdbc-42.5.0-1.mga9 > nextcloud-postgresql-24.0.5-3.mga9 > postgresql15-15.1-1.mga9 > postgresql15-plpgsql-15.1-1.mga9 > postgresql15-plpython3-15.1-1.mga9 > postgresql15-pltcl-15.1-1.mga9 > postgresql15-plperl-15.1-1.mga9 > postgresql15-pl-15.1-1.mga9 > postgresql15-contrib-15.1-1.mga9 > postgresql15-docs-15.1-1.mga9 > lodevbasis7.6-postgresql-sdbc-7.6.0.0.alpha0-1 > libgda5.0-postgres-5.2.10-4.mga9 How is it possible that you dont have postgresql15-server installed as it will remove also following packages when you uninstall it: - postgresql15-contrib-15.1-1.mga9.x86_64 - postgresql15-pl-15.1-1.mga9.x86_64 - postgresql15-plperl-15.1-1.mga9.x86_64 - postgresql15-plpgsql-15.1-1.mga9.x86_64 - postgresql15-plpython3-15.1-1.mga9.x86_64 - postgresql15-pltcl-15.1-1.mga9.x86_64 Where comes this package from as it is not available in any Magei repository: -lodevbasis7.6-postgresql-sdbc-7.6.0.0.alpha0-1
Good question... I was using PG 14 until PG 15 showed up and this is all I see with: rpm -qa --last postgresql15-pltcl-15.1-1.mga9.x86_64 Tue 27 Dec 2022 12:17:02 PM EST postgresql15-plpython3-15.1-1.mga9.x86_64 Tue 27 Dec 2022 12:17:02 PM EST postgresql15-plpgsql-15.1-1.mga9.x86_64 Tue 27 Dec 2022 12:17:02 PM EST postgresql15-plperl-15.1-1.mga9.x86_64 Tue 27 Dec 2022 12:17:02 PM EST postgresql15-pl-15.1-1.mga9.x86_64 Tue 27 Dec 2022 12:17:02 PM EST postgresql15-docs-15.1-1.mga9.noarch Tue 27 Dec 2022 12:17:02 PM EST postgresql15-contrib-15.1-1.mga9.x86_64 Tue 27 Dec 2022 12:17:02 PM EST postgresql15-15.1-1.mga9.x86_64 Tue 27 Dec 2022 12:17:02 PM EST Other recent update: libgda5.0-postgres-5.2.10-4.mga9.x86_64 Tue 03 Jan 2023 08:08:34 PM EST lodevbasis7.6-postgresql-sdbc-7.6.0.0.alpha0-1.x86_64 Sat 31 Dec 2022 10:42:35 AM EST is part of LibreOffice 7.6alpha; I use this alpha version extensively and have reported several bugs. Part of my using bleeding edge which has better support than released software... :)
...... And what happens when you install postgresql15-server????
If it helps, these are the packages that were installed the day before PG 15 arrived to update them: $ grep postgres RPMS.20221226 libgda5.0-postgres-5.2.10-3.mga9 lodevbasis7.6-postgresql-sdbc-7.6.0.0.alpha0-1 nextcloud-postgresql-24.0.5-3.mga9 postgresql14-14.5-1.mga9 postgresql14-docs-14.5-1.mga9 postgresql14-plpgsql-14.5-1.mga9 postgresql14-plpython3-14.5-1.mga9 postgresql14-pltcl-14.5-1.mga9 postgresql-jdbc-42.5.0-1.mga9 $ grep server RPMS.20221226 | grep postg and $ grep server RPMS* | grep postg return nothing... so no postgresql*-server was ever installed.
(In reply to sturmvogel from comment #8) > ...... > And what happens when you install postgresql15-server???? Hopefully nothing... what should I expect? I have several remote users accessing postgres databases; so I don't want to disrupt their queries.
Did you actually read comment 6? postgresql15-server is a requirement for postgresql15-contrib, postgresql15-pl, postgresql15-plperl, postgresql15-plpgsql, postgresql15-plpython3, postgresql15-pltcl So your installation looks manipulated (either by forcing --nodeps) and thats maybe one of the reasons why you have strange version numbers.
After installing postgresql15-server ... # rpm -q -f /usr/bin/postgres postgresql15-server-15.1-1.mga9 As the problem install doesn't show postgresql15-server or any other version of the server package installed, the command /usr/bin/postgres should not be found. It should show ... # rpm -q -f /usr/bin/postgres error: file /usr/bin/postgres: No such file or directory which is what I get after uninstalling it. How the 13.6 version of the package could have been uninstalled without deleting the file(s) from the package, I don't know, but it is not a result of anything normal. Installing postgresql13-server and then uninstalling it does not leave /usr/bin/postgres existing. Something happened to corrupt that installation or package updating. It's not from normal package install/uninstall. Please do a clean install to get back to a valid testing environment, since there's no way to know what else has been corrupted and bug reports based on that system are not productive. Closing as works for me.
Resolution: (none) => WORKSFORMEStatus: NEW => RESOLVED
Created attachment 13626 [details] rpm -qa --last Apparently as much as you read comment 7... Any manipulation was done by mcc. The only time I recall ever using --nodeps was in regards to the recent pulseaudio, pipewire, etc sound issue. As stated above, postgres*server has never been installed on this system; not because I didn't want to... it's what mcc decided. The oldest package listed by "rpm -qa --last" is: gpg-pubkey-80420f66-5d0d4576 Fri 25 Feb 2022 11:17:37 AM EST which is when I received this system. There is NO reference to any postgres server ever being installed/updated as evidenced by this attachment.
Another thought. What do you get for $ which postgres and $ which psql
$ which postgres /usr/bin/postgres $ which psql /usr/bin/psql $ ll /usr/bin/postgres -rwxr-xr-x 1 root root 8284760 Apr 13 2022 /usr/bin/postgres* $ ll /usr/bin/psql -rwxr-xr-x 1 root root 747456 Nov 15 03:28 /usr/bin/psql* $ /usr/bin/postgres --version postgres (PostgreSQL) 13.6 $ /usr/bin/psql --version psql (PostgreSQL) 15.1 Good catch Dave... so how did 13.6 get installed? There is no reference to PG13 anywhere I can find, other than the docs package in comment 4. No PG13 to PG14 update; just PG14 to PG15 on Dec 27... I can't imagine how PG13_anything could be in the system... Again, I have "rpm -qa" output for every day since May 10, and there is no mention of postgres*server in any of those files. I found some install/update logs from Fed 25 -- also no mention of postgres; let alone the server. So, somehow PG13.6 got magically installed Apr 13 (or that was its compile date), and never updated. It was never listed in any logs I can find. # strings /usr/bin/postgres | grep Mageia PostgreSQL 13.6 on x86_64-mageia-linux-gnu, compiled by gcc (Mageia 12.0.1-0.20220410.1.mga9) 12.0.1 20220410 (experimental), 64-bit indicates that it's a Mageia program. I always use mcc for installs/updates of Mageia packages. urpmi for things like firefox nightly, libreoffice 7.6alpha... Sigh... looks like I have a LOT of dump/restore work to do to install the server package: $ du -s /mnt/work/var/lib/* 392K /mnt/work/var/lib/pgadmin 2.4T /mnt/work/var/lib/pgsql Thanks! Later.
Resolution: WORKSFORME => FIXED
What's the output of "urpmq --list-url"?
Changing to invalid since nothing was changed in Mageia packages.
Resolution: FIXED => INVALID
(In reply to Dave Hodgins from comment #16) > What's the output of "urpmq --list-url"? $ urpmq --list-url Core Release http://mirrors.kernel.org/mageia/distrib/cauldron/x86_64/media/core/release Core Release Debug Core Updates http://mirrors.kernel.org/mageia/distrib/cauldron/x86_64/media/core/updates Core Updates Debug Core Updates Testing Core Updates Testing Debug Core Backports Core Backports Debug Core Backports Testing Core Backports Testing Debug Nonfree Release http://mirrors.kernel.org/mageia/distrib/cauldron/x86_64/media/nonfree/release Nonfree Release Debug Nonfree Updates http://mirrors.kernel.org/mageia/distrib/cauldron/x86_64/media/nonfree/updates Nonfree Updates Debug Nonfree Updates Testing Nonfree Updates Testing Debug Nonfree Backports Nonfree Backports Debug Nonfree Backports Testing Nonfree Backports Testing Debug Tainted Release http://mirrors.kernel.org/mageia/distrib/cauldron/x86_64/media/tainted/release Tainted Release Debug Tainted Updates http://mirrors.kernel.org/mageia/distrib/cauldron/x86_64/media/tainted/updates Tainted Updates Debug Tainted Updates Testing Tainted Updates Testing Debug Tainted Backports Tainted Backports Debug Tainted Backports Testing Tainted Backports Testing Debug Core 32bit Release Core 32bit Updates Core 32bit Updates Testing Core 32bit Backports Core 32bit Backports Testing Nonfree 32bit Release Nonfree 32bit Updates Nonfree 32bit Updates Testing Nonfree 32bit Backports Nonfree 32bit Backports Testing Tainted 32bit Release Tainted 32bit Updates Tainted 32bit Updates Testing Tainted 32bit Backports Tainted 32bit Backports Testing MLO_core https://mageialinux-online.org/repository/8/x86_64/media/core MLO_nonfree https://mageialinux-online.org/repository/8/x86_64/media/nonfree MLO_tainted https://mageialinux-online.org/repository/8/x86_64/media/tainted
Resolution: INVALID => FIXED
Having mlo repositories makes that install useless for debugging problems that may exist in Mageia cauldron, as requires and provides from those packages are very likely to interfere with Mageia packages. Any bugs you find in that system, please ensure you can recreate the bug in an install that only has ever had packages from Mageia.
Please don't change back the resolution that David set. See comment 17.
I did not knowingly change it; I don't care what the system claims. Besides, under what logic would I, as reporter with still no final solution, be motivated to make such a change...?
(In reply to Dave Hodgins from comment #19) > Having mlo repositories makes that install useless for debugging problems > that > may exist in Mageia cauldron, as requires and provides from those packages > are very likely to interfere with Mageia packages. I added those to get a working 'signal-desktop' -- see discuss list on Dec 22, Subject: Signal ... What "urpmq --list-url" output fails to show are the checkbox selections: disabled.
The problem is having leftover postgresql 13 files from mga8 in the filesystem, without still having the packages they came from installed. The system has packages that require the postgresql server, but the server is not installed. The rpm -qa --last command only shows when currently installed packages were installed. It doesn't show packages that were present but no longer are present. If the journal goes back far enough, it may or may not show what what done to trigger the problem, but it's not worth the effort to reconstruct. The most likely cause of not having the postgresql server packages is installing the other postgresql packages and overriding the check for missing dependencies (the server), which can easily happen in cauldron if the mirror was synced during the building of the postgresql server package. Having /usr/bin/postgres from m8 without having the package installed requires either manually copying the file from an m8 install, or something that caused file system corruption such as a loss of power while writing. Any manual manipulation of the file system would not show in the journal. The fix for postgresql is to uninstall all of the postgresql packages that are currently installed, and then reinstall them properly, which would also install the postgresql server. Given that the system is corrupt, fixing the postgresql problem isn't worth doing. Do not trust it for testing. This is cauldron. Re-install to get to a known clean state. Be sure to format the file system, not reinstall over it. Any bug reports from a system that is known to be corrupt are invalid. The corruption didn't happen due to normal rpm install/uninstall, but due to other causes, as above.