PMG renders the postgresql.conf through its templating system (currently the
shipped template does not use any variables). postgresql.conf (in most
installations and in both debian and upstream packages) contains a few
occurrences (datadir, config files, pid-file, cluster name) of the postgres
major version number (see [0], for a description and why 9.6 and 11 are major
version numbers). The rendered config should use the correct version number
for the config of the currently used postgres installation (the one listening
on the default port (5432) and socket).
This fixes a bug observed while testing the upgrade to buster and postgres 11:
* a long running service (pmgmirror, pmgdaemon) still has the old config
path in memory (/etc/postgresql/9.6/)
* while upgrading the pmg-api package the shipped template changes to one
with the new major number (11)
* the next restart of the postgresql cluster fails, with an error not directly
related to the broken config file
By reading [1] the version number through a connection to the current
postgresql server we rewrite the fitting configfile with the correct paths.
[0] https://www.postgresql.org/support/versioning/
[1] https://www.postgresql.org/docs/11/runtime-config-preset.html
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
die "setresuid back failed - $!\n";
}
+sub get_pg_server_version {
+ my $major_ver;
+ my $parser = sub {
+ my $line = shift;
+ # example output:
+ # 9.6.13
+ # 11.4 (Debian 11.4-1)
+ # see https://www.postgresql.org/support/versioning/
+ my ($first_comp) = ($line =~ m/^\s*([0-9]+)/);
+ if ($first_comp < 10) {
+ ($major_ver) = ($line =~ m/^([0-9]+\.[0-9]+)\.[0-9]+/);
+ } else {
+ $major_ver = $first_comp;
+ }
+
+ };
+ eval {
+ postgres_admin_cmd('psql', { outfunc => $parser }, '--quiet',
+ '--tuples-only', '--no-align', '--command', 'show server_version;');
+ };
+
+ die "Unable to determine currently running Postgresql server version\n"
+ if ($@ || !defined($major_ver));
+
+ return $major_ver;
+}
+
1;