Regression in postgresql_info for 3.10.0

[eb4x]

SUMMARY

A task using postgresql_info gathering in_recovery, stopped working in 3.10.0 collection.

ISSUE TYPE

• Bug Report

COMPONENT NAME

postgresql_info

ANSIBLE VERSION

ansible [core 2.16.13]
  config file = /home/erikberg/src/dia-ansible/ansible.cfg
  configured module search path = ['/home/erikberg/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/erikberg/.local/lib/python3.13/site-packages/ansible
  ansible collection location = /home/erikberg/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/erikberg/.local/bin/ansible
  python version = 3.13.1 (main, Dec  9 2024, 00:00:00) [GCC 14.2.1 20240912 (Red Hat 14.2.1-3)] (/usr/bin/python3)
  jinja version = 3.1.4
  libyaml = True

COLLECTION VERSION

Collection           Version
-------------------- -------
community.postgresql 3.10.0 

CONFIGURATION

OS / ENVIRONMENT

EL9 (almalinux)

STEPS TO REPRODUCE

  tasks:
    - name: Get in_recovery on postgresql
      become: true
      become_user: postgres
      community.postgresql.postgresql_info:
        filter: in_recovery
      register: _pgsql_info

EXPECTED RESULTS

It just works, like in 3.9.0

ACTUAL RESULTS

An exception occurred during task execution. To see the full traceback, use -vvv. The error was: KeyError: 'login_db'
fatal: [server.vagrant.local]: FAILED! => {"changed": false, "module_stderr": "Shared connection to server.vagrant.local closed.\r\n", "module_stdout": "Traceback (most recent call last):\r\n  File \"/var/tmp/ansible-tmp-1737370726.9350688-583628-240187215419414/AnsiballZ_postgresql_info.py\", line 107, in <module>\r\n    _ansiballz_main()\r\n  File \"/var/tmp/ansible-tmp-1737370726.9350688-583628-240187215419414/AnsiballZ_postgresql_info.py\", line 99, in _ansiballz_main\r\n    invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)\r\n  File \"/var/tmp/ansible-tmp-1737370726.9350688-583628-240187215419414/AnsiballZ_postgresql_info.py\", line 47, in invoke_module\r\n    runpy.run_module(mod_name='ansible_collections.community.postgresql.plugins.modules.postgresql_info', init_globals=dict(_module_fqn='ansible_collections.community.postgresql.plugins.modules.postgresql_info', _modlib_path=modlib_path),\r\n  File \"/usr/lib64/python3.9/runpy.py\", line 225, in run_module\r\n    return _run_module_code(code, init_globals, run_name, mod_spec)\r\n  File \"/usr/lib64/python3.9/runpy.py\", line 97, in _run_module_code\r\n    _run_code(code, mod_globals, init_globals,\r\n  File \"/usr/lib64/python3.9/runpy.py\", line 87, in _run_code\r\n    exec(code, run_globals)\r\n  File \"/tmp/ansible_community.postgresql.postgresql_info_payload_rirhzlri/ansible_community.postgresql.postgresql_info_payload.zip/ansible_collections/community/postgresql/plugins/modules/postgresql_info.py\", line 756, in <module>\r\n  File \"/tmp/ansible_community.postgresql.postgresql_info_payload_rirhzlri/ansible_community.postgresql.postgresql_info_payload.zip/ansible_collections/community/postgresql/plugins/modules/postgresql_info.py\", line 750, in main\r\n  File \"/tmp/ansible_community.postgresql.postgresql_info_payload_rirhzlri/ansible_community.postgresql.postgresql_info_payload.zip/ansible_collections/community/postgresql/plugins/modules/postgresql_info.py\", line 233, in __init__\r\nKeyError: 'login_db'\r\n", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", "rc": 1}

[realwhite]

+1.
db/login_db parameter is specified in the documentation as optional, but PR 788 imply that it should be or should have a default value inside the module itself.

[JosDeGraeve]

+1

I was using the db parameter. Replacing it with login_db succeeded as a workaround for me.

[Andersson007]

Hello, thanks for reporting the issue!
@kacperk could you please take a look ASAP?

[Andersson007]

Hello, thanks for reporting the issue! @kacperk could you please take a look ASAP?

@kacperk I'm looking myself, fyi. I guess your initial suggestion was correct and mine wrong. The problem was also that we test only using login_db.

[Andersson007]

Reproduced and added your original code #796, also added a test task that tests it with db, thanks

[Andersson007]

The community.postgresql collection version 3.10.1 has been released, just update it using ansible-galaxy, thanks everyone!

[realwhite]

@Andersson007, what about case when do not use db or login_db?

For example, get from docs:

- name: Collect PostgreSQL version and extensions
  become: true
  become_user: postgres
  community.postgresql.postgresql_info:
    filter: ver*,ext*

[Andersson007]

@realwhite great point, thanks
Should we hardcode postgres in case those i added are not specified or it's better to query the current DB after we login?
(I'm not a user and I would avoid adding extra code if postgres is the only option as the default DB)
@realwhite @hunleyd and other folks, what do you think? I could add and release it tomorrow, FYI

[kacperk]

@Andersson007 as far as I know, default behavior for Postgres connections is to connect to the database called the same as username, so not necessarily postgres. I think the safest solution is to query db name if we cannot get it from parameters.

[realwhite]

@Andersson007 from documentation for initdb:

The postgres database is a default database meant for use by users, utilities and third party applications.

but in the documentation for libpq (dbname parameter in connection string):

Defaults to be the same as the user name

But, don't think it's necessary to enter a parameter like default_db on module level.

Actually, except for the case that @kacperk solved, it doesn't seem to make any difference which database to reconnect to.

There are several options to consider:

• use postgres because it always exists.
• use any database that belongs to the user you are connected to. (in that section of the code, we got this info)
• determine by privileges which database has CONNECT permission and reconnect to it (requires writing some code)

Or use all of this methods together, by priority:

1. db parameter (if specify)
2. db called the same as user (if exists)
3. db owned by user (if exists)
4. postgres (fallback option)

[Andersson007]

@kacperk @realwhite thanks for your feedback!
I opened #798
I just get the current DB at the beginning of execution, so it should be the default one
Ready for review

[hunleyd]

use postgres because it always exists.

many of our customers remove this database so 3rd party tools don't create objects outside the normal review process. if you want a db that is going to be there for sure, i'd use template1

[Andersson007]

The community.postgresql collection version 3.10.2 has been released. Thanks everyone!