Postgresql::Server::Config_entry uninitialized constant ParserError

[jlindquist-godaddy]

Describe the Bug

Error: /Stage[main]/Postgresql::Server/Postgresql::Server::Config_entry[shared_buffers]/Postgresql_conf[shared_buffers]: Could not evaluate: uninitialized constant ParserError
Did you mean?  ParseError
Notice: /Stage[main]/Postgresql::Server::Service/Postgresql::Server::Instance::Service[main]/Anchor[postgresql::server::service::begin::main]: Dependency Postgresql_conf[shared_buffers] has failures: true

Expected Behavior

Catalog compilation does not fail, and config entry is properly validated and set as necessary

Steps to Reproduce

Include server config entries from Hiera

postgresql::server::config_entries:
  max_connections: 300
  shared_buffers: 4GB

Environment

• Version 10.0.1
• Platform CentOS 7

Additional Context

It looks like we're triggering the error here based on a config such as this which does have multiple entries that need to be resolved, but it should raise a proper error:

# grep shared_buffers /var/lib/pgsql/14/data/postgresql.conf
shared_buffers = 128MB # min 128kB
#wal_buffers = -1			# min 32kB, -1 sets based on shared_buffers
shared_buffers = 4GB

[bastelfreak]

@jlindquist-godaddy can you take a look at #1538 and test it?

[jlindquist-godaddy]

Looks good, thank you!

[ekolkman]

I just ran into this bug with version 10.0.3 of the module.
Easily reproducable: have multiple listen_addresses lines in the postgresql.conf file (values don't matter) and configure a server with a listen_addresses parameter set to a value.
(Postgres itself usually doesn't mind multiple entries for the same parameter, as only the last one is used. But this version of the module doesn't accept it and now gives an error about giving the error.)

[ekolkman]

Problem persists in 10.1.0.
Reproducable by adding any entry in the postgresql.conf a second time (doesn't matter if the value differs).
Having an override of the value in the postgresql.auto.conf (normally managed from postgresql itself using 'ALTER SYSTEM ...') statements doesn't show the same error.

So there are 2 problems:

• a situation accepted by postgresql itself is not accepted by this module
• the errormessage for this situation produces its own error (and the last one is the only one visible in the puppet logs)