Solved postgresql 14 pkg with KDE ?

B

bgroper

Hi forum
I have a fairly fresh install of 13.1-RELEASE-p2.
I start to install postgres14-server, BUT am troubled by the installation process wanting to remove kde5, and other possibly important packages.
Does this mean I should instead use an older postgres version (13 ?), with a shorter use-by date ?
Or install the postgresql14-server on a FreeBSD headless server ?
Thx for any tips or suggestions. Clip below from my cli session.
(Yes, I'm new to FreeBSD, being another refugee from the IBM/Redhat takeover of CentOS.)

Code: 
root@freebsd:~ # pkg install postgresql14-server
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking integrity... done (2 conflicting)
  - postgresql14-client-14.4 conflicts with postgresql13-client-13.7 on /usr/local/bin/clusterdb
  - postgresql14-client-14.4 conflicts with postgresql13-client-13.7 on /usr/local/bin/clusterdb
Checking integrity... done (0 conflicting)
The following 12 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
        frei0r-plugins: 1.8.0
        frei0r-plugins-opencv: 1.8.0
        gdal: 3.5.0_1
        kde5: 5.24.6.22.04.3
        kdemultimedia: 22.04.3_1
        kdenlive: 22.04.3
        opencv: 4.5.5_7
        postgresql13-client: 13.7

New packages to be INSTALLED:
        postgresql14-client: 14.4
        postgresql14-server: 14.4

Installed packages to be REINSTALLED:
        pkg-1.18.3
        qt5-webchannel-5.15.5p3

Number of packages to be removed: 8
Number of packages to be installed: 2
Number of packages to be reinstalled: 2

The operation will free 208 MiB.

Proceed with this action? [y/N]: N

root@freebsd:~ #
 
The default postgresql-version is currently 13. So all packages are built against it and depend on that version.
So you have to use that version for everything.
You can however install a different postgresql-version in a jail and run the server on a different port.
 
Additionally to the given answer: By using ports instead of packages you could change the default PostgreSQL version; But that's IMO only an option if you really need 14 - otherwise it's overkill.
And KDE5 won't be deinstalled: Just Kdenlive, kdemultimedia and the meta package - the meta package does not contain anything beyond dependencies to other packages, which won't be deinstalled (only the multimedia part and its environment); It just forces other packages to be installed. But by removing the meta package you've got to take sure by yourself if you're executing f.e. a pkg autoremove.
 
Thanks for replies and explanation.
I'm happy to go with postgres 13 for the moment.
But will need to plan an upgrade path before version 13 becomes end-of-life in ~ November 2025.
Should be enough time. ;)
 
It occurs to me, how should (or could ?) I have known to use postgresql13 rather than another version, or discovered this important knowledge without troubling this forum ?
Perhaps this wisdom simply emerges with experience ?
Same question applies to which version of phppgadmin should I be using ?

Code: 
root@freebsd:/etc # pkg search pgadmin
phppgadmin-php74-7.13.0_1      Web Based Postgres Administration
phppgadmin-php80-7.13.0_1      Web Based Postgres Administration
phppgadmin-php81-7.13.0_1      Web Based Postgres Administration
phppgadmin-php82-7.13.0_1      Web Based Postgres Administration

More TIA's
 
bgroper said:
It occurs to me, how should (or could ?) I have known to use postgresql13 rather than another version, or discovered this important knowledge without troubling this forum ?
Click to expand...
Check /usr/ports/Mk/bsd.default-versions.mk: https://cgit.freebsd.org/ports/tree/Mk/bsd.default-versions.mk

Code: 
# Possible values: 10, 11, 12, 13, 14, 15
PGSQL_DEFAULT?=		13

This file has all the defaults, if you build from ports you can actually overrule them. For PostgreSQL you could set this in make.conf(5):
Code: 
DEFAULT_VERSIONS+= pgsql=14
Which would set the default PostgreSQL version to 14.

Ports are created using specific options, if a port requires a PostgreSQL client for example, it would add:
Code: 
USES= pgsql
That will be a signal to the build system to include whatever PostgreSQL client version is set as default.

The official packages are always build with the defaults as set in bsd.default-versions.mk. So if you want to know what the default MySQL, or PHP, or Java, or Python version is for example, look at that file.

bgroper said:
Same question applies to which version of phppgadmin should I be using ?
Click to expand...
Some ports (unfortunately not all of them) can have different flavors. So this port in particular has been built with different PHP version flavors. Which means you can install the package in your preferred version of PHP.
 
bgroper said:
It occurs to me, how should (or could ?) I have known to use postgresql13 rather than another version, ...
Click to expand...
Packages are build from ports, ports have default versions specified in file ports/MK/bsd.default-versions.mk (which can be overruled setting another supported version in /etc/make.conf when building from ports). When using ports-mgmt/pkg search in that file for default versions, e.g. PGSQL:

bsd.default-versions.mk « Mk - ports - FreeBSD ports tree

cgit.freebsd.org cgit.freebsd.org

bgroper said:
Same question applies to which version of phppgadmin should I be using ?
Click to expand...
That would be version 8.0

bsd.default-versions.mk « Mk - ports - FreeBSD ports tree

cgit.freebsd.org cgit.freebsd.org

See # Possible values: above the *_DEFAULT line for supported versions.
 
bgroper said:
It occurs to me, how should (or could ?) I have known to use postgresql13 rather than another version, or discovered this important knowledge without troubling this forum ?
Click to expand...
You're perfectly welcome. Upgrade paths are an interestimg matter.
I am currently using postgresql12 sitewide, because with 13 the streaming file-system level backup does no longer work the way we are used to it (*), and discussions with the developers were futile. :(
Now finally I have written a python plugin for sysutils/bareos-client to cope with the crap&ugliness of the new design, and am now pondering about moving onwards.
Sadly, FreeBSD does not (officially) allow to install multiple versions of postgres on the same node, so some of the commonly recommended upgrade methods will not work or need extra maneuvers.


(*) The provided tooling does just not work: pg_basebackup can stream to stdout only with the tar format, and that cannot be used with tablespaces. (AFAIK most of the available tools do just bulk the entire data onto another diskspace and then stream from there.)
And doing it low-level needs close interaction between the backup system and the database:
  1. backup system must notify the postgres instance on backup start
  2. backup system operates the file-level backup
  3. when successful, backup system must notify the postgres instance on backup completion, but -now the crap comes- this must happen in the same database connection as in step 1. (So this connection must be kept open during the backup)
  4. in reply the postgres instance will provide some vital data concerning the backup
  5. Finally the backup system must re-open the already closed backup stream (mega-crap!) and add that vital data into the required file locations.
Now try to implement this fully failsafe and automated with proper error handling on any commonly used backup system. :(
 
SirDice said:
PMc have you looked at databases/pgbackrest? The DBAs at $DAYJOB use it (I don't have much to do with databases, just the systems).
Click to expand...
Yes. This one maintains it's own "repository" of backups, it does not integrate into any existing backup solution. From the Webpage:
Backups in the repository are stored in the same format as a standard PostgreSQL cluster (including tablespaces).
Click to expand...

So you end up having three entities to maintain: the actual postgres clusters, the actual backup solution (that cares for things like mirroring, retention, offsite, longterm, etc.), and this intermediate "repository" with it's own ideas of incremental/differential, retention, etc.etc. (which basically re-invents a backup solution).

P.S: this may be well suited for sites with a separate DBA team, because the DBA then have their own backup repo they can manage, and do not need to interact with the global backup scheme.
 
Oh wow, and more thanks.
I'm grateful for all the help lifting me from the very bottom of the learning curve.
Reminds me of an old story about giving a fish to hungry man. Better to show him how to go fishing for himself. Something like that ... ;)
 
A few variations: Give a man a fish, and he is fed for a day. Teach him how to fish, and he will waste every Saturday on the lake drinking beer, spend all his money on fishing gear, and still eat burgers.

Steal a man's wallet, and he is poor for a week. Teach him how to play percussion, and how to buy music gear, and he is poor for life.
 
You must log in or register to reply here.
Back
Top