Bug reference: 17735 Logged by: Sam Bortman Email address: sam.bortman@gmail.com PostgreSQL version: 15.1 Operating system: Linux (Debian-based) Description:
Hello,
The following is likely only an issue with the Devian-based distributions and should be passed along to the package maintainer. I have no access to other Linux systems to try this on. It may be a common issue, but I have no way to verify this, currently.
I discovered an issue while having two versions of PostgreSQL (namely 14.x and 15.1) installed side-by-side on an Ubuntu-based server. There were absolutely no issues, or conflicts, nor were there any sort of negative interaction between the versions at run-time. It worked like a charm!
When I issued an "sudo apt purge postgresql-14" command I was presented with the familiar prompt of whether I wanted to wipe and data directory associated with my PG 14 cluster. I replied in the affirmative. As expected /var/lib/postgresql/14 was gone. So, far so good.
However, the /var/log/postgresql directory was also wiped in its entirety. The directory has previously hosted both postgresql-14-main.log* log files, as well as postgresql-15-main.log* files.
Expected behavior: Since PG allows different versions to be installed concurrently, ideally only the logs which embed the version number of the product being uninstalled should be purged. In my case, postgresql-14-main.log* should have been removed, to the exclusion of all other installed versions.
I realize that Debina-based installations do not make use log_filename, which makes it possible to infer the product version from the log filename (as mentioned above), whereas on other distributions it may be impossible to tell which log file was created with which version.
So perhaps you want to consider excluding all log files from deletion when such version-determination is impossible. Or perhaps the uninstallation script on such distributions should parse to postgresql.conf file to determine the value of log_filename is so that it knows what pattern to delete. Nothing is fool-proof, but perhaps this is better than nothing?)
