[SOLVED] postgresql upgrade during Mageia upgrade?

[magfan]

Will postgresql-8.4 be automatically upgraded to version 9.* during upgrade from mga3 to mga4? Version 8.4 does not exist in mga4 any more...

[doktor5000]

It should.

See for more info:

https://ml.mageia.org/wwsympa-wrapper.f ... 00937.html
https://ml.mageia.org/l/arc/dev/2014-01/msg00937.html

[magfan]

How can I avoid this? I am using a commercial backup software which requires postgresql-8.4. Newer versions are not supported. And I do need to have access to my old backups.

[doktor5000]

Put postgresql into skip.list.

/etc/urpmi/skip.list
The list of packages that should not be automatically updated when using --auto-select. It contains one package expression per line; either
a package name, or a regular expression (if enclosed in slashes /) to match the name of packages against. (Actually, it's matched against
the full name of the package, which has the form name-version-release.arch.)

[magfan]

Put postgresql into skip.list.

/etc/urpmi/skip.list
The list of packages that should not be automatically updated when using --auto-select. It contains one package expression per line; either
a package name, or a regular expression (if enclosed in slashes /) to match the name of packages against. (Actually, it's matched against
the full name of the package, which has the form name-version-release.arch.)

Do I have to add all dependencies myself or will urpmi check for it?

[doktor5000]

The dependencies will not be pulled in if postgresql is skipped.

Code: Select all

/.*postgres.*/

should be sufficient IMHO.

[magfan]

What are the upgrade rules / dependencies when upgrading mga3 -> mga4?

There are several postgresql packages in mga3 (8.4, 9.0, 9.1, 9.2) and mga4 (9.0, 9.1, 9.2, 9.3). But there is no version 8.4 anymore in mga4 so I guess that this package (postgresql8.4) will be upgraded to a higher version if it is not in the skip list. But to which version? Will an installation of postgresql9.1 also be upgraded to a higher version? If not I may upgrade our commercial software package to be used with postgresql9.1 prior to upgrading the whole system.

[doktor5000]

What are the upgrade rules / dependencies when upgrading mga3 -> mga4?

In general packages with same name will be upgraded to newer versions. For postgresql, version is contained in name so the general rule does not apply.

There are several postgresql packages in mga3 (8.4, 9.0, 9.1, 9.2) and mga4 (9.0, 9.1, 9.2, 9.3). But there is no version 8.4 anymore in mga4 so I guess that this package (postgresql8.4) will be upgraded to a higher version if it is not in the skip list. But to which version?

You can choose to which version you want to upgrade. This is the same for all packages where multiple packages provide the same thing.

Will an installation of postgresql9.1 also be upgraded to a higher version? If not I may upgrade our commercial software package to be used with postgresql9.1 prior to upgrading the whole system.

If there's also an mga4 version of postgresql9.1, then postgresql9.1-mga3 would be updated to postgresql9.1-mga4.

Why not simply run urpmi --auto-update --test and see for yourself? (no installation will happen, but in the first update round only priority updates will be shown

[magfan]

Why not simply run urpmi --auto-update --test and see for yourself? (no installation will happen, but in the first update round only priority updates will be shown

OK, I first have to remove all mga3 repositories and then add mga4 repositories. That is OK because I can revert this change. But what do you mean with first update round and priority updates? Will there be a second round only after the changes from the first round have been made to the system? This would mean that I may run into real problems! What if I discover in the second round that packages will be upgraded which I prefer to keep? Sometimes it is better not to ask too many questions and just do it. But since our backup software relies on specific software packages I have only one single shot. If I fail I will not even have access to my backups...

[doktor5000]

Priority updates are urpmi, rpm, perl-URPM, librpm and friends.

If that update is so criticial, why not simulate it inside a VM beforehand? Why the urge to upgrade to Mageia 4?

[magfan]

If that update is so criticial, why not simulate it inside a VM beforehand? Why the urge to upgrade to Mageia 4?

Well, I would love to stick with Mageia although problems like this may always occur. The main reason is a long update/upgrade cycle for some commercial packages and a pretty short update/upgrade cycle for Mageia. According to my experience it is easier to upgrade Mageia before too many updates for this new version have been released. Usually I try such upgrades in a VM beforehand, especially for kernel upgrades. But once I had later some issues with the "real hardware" because I did not realize that dracut did not include certain kernel modules for my hardware RAID (viewtopic.php?f=7&t=3383&hilit=+dracut).

[magfan]

There is a problem with the postgresql installation. I decided to remove all postgresql related packages and to install postgresql9.1 completely new. But something is really strange. Even after removing everything via mcc there is still a postgesql server running. Version 8.4.17 has not been removed but I cannot find the package it belongs to:

Code: Select all

# pg_ctl --version
pg_ctl (PostgreSQL) 8.4.17

How can I remove that server if mcc does not see it and also "rpm -qa | grep postgres" does not show it?

[doktor5000]

File was unlinked but filehandle is still open? Or it's only running in memory ...

What about

Code: Select all

which pg_ctl
rpm -qf $(which pg_ctl)
killall -15 pg_ctl

[magfan]

OK, that part could be solved. But still postgres behaves strangely. It complains that it cannot start because of memory problems:

Code: Select all

$ FATAL:  could not create shared memory segment: Invalid argument                                                                   
DETAIL:  Failed system call was shmget(key=5432001, size=41205760, 03600).                                                                                 
HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter.  You can either reduce the request size or reconfigure the kernel with larger SHMMAX.  To reduce the request size (currently 41205760 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.                                                                                                     
        If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter, in which case raising the request size or reconfiguring SHMMIN is called for.                                                                                                                       
        The PostgreSQL documentation contains more information about shared memory configuration.                                                         


The strange thing is that in /etc/sysctl.conf the kernel values are set as follows:

Code: Select all

kernel.shmmax=8589934592
kernel.shmall=2097152


[magfan]

OK, the main issue with regard to the topic has been solved: I could keep the desired postgresql packages during upgrade. The memory issue influences postgresql but it will become a separate topic.

[magfan]

The situation is even worse than I thought. It is true that the version number of postgresql was kept. There was a smooth exchange from postgresql9.1-mga3 to postgresql9.1-mga4. But... The new package causes severe problems. In mga3 the socket files were created in /var/run/postgresql. In mga4 these files are created in /tmp - with no possibility to change this behaviour because any setting of "unix_socket_directory" will be ignored (https://forums.mageia.org/en/viewtopic.php?f=7&t=7205)!