Ansible-role-postgresql: Can't change postgres_version

Created on 2 Sep 2020  ·  10Comments  ·  Source: geerlingguy/ansible-role-postgresql

Adding var postgresql_version: "12" doesn't change actual version which was installed in VM with Ubuntu 18.

stale

Most helpful comment

Hello. I'm not 100% sure of this but if you specify a different version of PostgreSQL using postgresql_version, you need to configure the rest of the postgres_ variables. Otherwise, it will use the defaults from ./vars/<OS>-<version>.yml for the variables you did not define and will conflict with the version you wish to install.

For example, in my CentOS 6 test environment, I wanted to install PostgreSQL v9.6. That version of PostgreSQL is not in the standard CentOS repositories. The highest version of PostgreSQL in the standard CentOS repositories is I believe v8.4. These playbooks by Jeff only use the default repositories. Verify that the version of PostgreSQL you wish to install is in the repositories enabled on your server. In my case, I had to install the official PostgreSQL v9.6 yum repositories before configuring the role:

- name: Install PostgreSQL 9.6 Repository
  yum_repository:
    name: postgresql96
    baseurl: https://download.postgresql.org/pub/repos/yum/9.6/redhat/rhel-$releasever-$basearch
    enabled: True
    file: postgresql96
    description: PostgreSQL 9.6 for RHEL/CentOS $releasever - $basearch
    gpgcheck: False

I added the following variables to ./vars/main.yml NOTE: This file did not exist and had to be created. Also, note the variables below only work on RHEL-based distributions. These will be different for Debian-based distributions.

postgres_users_no_log: false # not needed; enabled for troubleshooting
postgresql_version: "9.6"
postgresql_data_dir: /var/lib/pgsql/9.6/data
postgresql_bin_path: /usr/pgsql-9.6/bin
postgresql_config_path: /var/lib/pgsql/9.6/data
postgresql_daemon: postgresql-9.6
postgresql_packages:
  - postgresql96
  - postgresql96-libs
  - postgresql96-server

Once you have all these variables defined, it will hopefully work for you as well.

All 10 comments

Also noticed this on Debian 10

roles/postgres.yml

- name: Install Postgres
  become: yes
  become_method: sudo
  include_role:
    name: geerlingguy.postgresql
  vars:
    postgresql_version: "12"

@geerlingguy is it possible to specify a custom psql version that will be installed via this ansible role?

Problem

This role does not support installing custom PSQL version to the destination platform.

Notes

postgresql_version: [OS-specific]
postgresql_data_dir: [OS-specific]
postgresql_bin_path: [OS-specific]
postgresql_config_path: [OS-specific]
postgresql_daemon: [OS-specific]
postgresql_packages: [OS-specific]
---------------------------------------

OS-specific variables that are set by include files in this role's vars
directory. These shouldn't be overridden unless you're using a version
of PostgreSQL that wasn't installed using system packages.

The default PSQL version is defined in ./vars/<OS>-<version>.yml, e.g.:
https://github.com/geerlingguy/ansible-role-postgresql/blob/master/vars/RedHat-7.yml#L2

Example

Platform:

  • CentOS-7

    • includes systemd

    • includes sshd

    • container (setup)

Playbook:

---
- hosts: container # src: https://hub.docker.com/r/europ/docker-centos-sshd-systemd
  gather_facts: true
  tasks:
    - block: # workaround, see https://stackoverflow.com/a/56558842
        - name: PSQL installation and configuration
          include_role:
            name: geerlingguy.postgresql
          vars:
            postgresql_users:
              - name: abc
                password: abc
            postgresql_databases:
              - name: xyz
            postgresql_version: "10.4" # override psql-9.2 with custom version (psql-10.4)
      become: true

Result:

psql -V
# psql (PostgreSQL) 9.2.24

Same for me on debian 10 ....

Hello. I'm not 100% sure of this but if you specify a different version of PostgreSQL using postgresql_version, you need to configure the rest of the postgres_ variables. Otherwise, it will use the defaults from ./vars/<OS>-<version>.yml for the variables you did not define and will conflict with the version you wish to install.

For example, in my CentOS 6 test environment, I wanted to install PostgreSQL v9.6. That version of PostgreSQL is not in the standard CentOS repositories. The highest version of PostgreSQL in the standard CentOS repositories is I believe v8.4. These playbooks by Jeff only use the default repositories. Verify that the version of PostgreSQL you wish to install is in the repositories enabled on your server. In my case, I had to install the official PostgreSQL v9.6 yum repositories before configuring the role:

- name: Install PostgreSQL 9.6 Repository
  yum_repository:
    name: postgresql96
    baseurl: https://download.postgresql.org/pub/repos/yum/9.6/redhat/rhel-$releasever-$basearch
    enabled: True
    file: postgresql96
    description: PostgreSQL 9.6 for RHEL/CentOS $releasever - $basearch
    gpgcheck: False

I added the following variables to ./vars/main.yml NOTE: This file did not exist and had to be created. Also, note the variables below only work on RHEL-based distributions. These will be different for Debian-based distributions.

postgres_users_no_log: false # not needed; enabled for troubleshooting
postgresql_version: "9.6"
postgresql_data_dir: /var/lib/pgsql/9.6/data
postgresql_bin_path: /usr/pgsql-9.6/bin
postgresql_config_path: /var/lib/pgsql/9.6/data
postgresql_daemon: postgresql-9.6
postgresql_packages:
  - postgresql96
  - postgresql96-libs
  - postgresql96-server

Once you have all these variables defined, it will hopefully work for you as well.

note for postgresql 10, you need to add the right repo in first

For me it also blindly installs postgres 13 when postgresql_version: 12 is specified

The version is not changing because it's hardoded there for example:

I've created #156 , hopefully it gets approved and merged. Meanwhile it can be used with ansible-galaxy install aviatrix.postgresql

This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution!

Please read this blog post to see the reasons why I mark issues as stale.

This issue has been closed due to inactivity. If you feel this is in error, please reopen the issue or file a new issue with the relevant details.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

worldofchris picture worldofchris  ·  8Comments

breml picture breml  ·  9Comments

svanschalkwyk picture svanschalkwyk  ·  6Comments

FilBot3 picture FilBot3  ·  18Comments

NiftyMist picture NiftyMist  ·  5Comments