Bug 31354

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.rpm
Assignee: 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) => WORKSFORME
Status: 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.

Resolution: FIXED => INVALID

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.