Custom 'listen_addresses' not applied

[cornel-masson]

Overview

After configuring for listen_addresses = "*", the db is still created with listen_addresses = "0.0.0.0".

Environment

Please provide the following details:

• Platform: Kubernetes
• Platform Version: 4.7.3
• PGO Image Tag: centos8-4.7.
• Postgres Version: 13
• Storage: hostpath

Steps to Reproduce

REPRO

According to the documentation, you can customize listen_addresses by setting postgresql.listen. I created a custom configmap - hippo-custom-config - with an entry for postgres-ha.yaml, which has listen: '*':

Data
====
postgres-ha.yaml:
----
bootstrap:
  dcs:
    postgresql:
      parameters:
        shared_preload_libraries: pg_stat_statements.so,pgnodemx.so,timescaledb
        listen: '*'

I then created the cluster, with --custom-config pointing to hippo-custom-config:

pgo create cluster hippo --custom-config=hippo-custom-config

I then created a port-forward to the hippo database, and used psql to connect.

EXPECTED

When I show listen_addresses; in psql, I expect to see "*".

ACTUAL

When I show listen_addresses; in psql, I see the default "0.0.0.0", not my custom "*".
I also opened a shell into the 'hippo' pod and looked at the running processes (ps -fA). It shows the postgres process started with an explicit listen_addresses parameter of "0.0.0.0":

postgres -D /pgdata/hippo --config-file=/pgdata/hippo/postgresql.conf --listen_addresses=0.0.0.0

According to the documentation, listen_addresses is one of the few parameters that is set in this way, rather than in postgresql.conf itself. I expect to see the parameter passed in as listen_addresses=*.

[jkatz]

If this is a new deployment, I suggest using v5.

That said, as PGO manages the networking for Postgres clusters (and as such, manages listen_adresses), there's no reason to modify the listen_addresses configuration parameter. If you need to manage networking or networking access, you can do that by setting the pg_hba config or using NetworkPolicies.

[cornel-masson]

If this is a new deployment, I suggest using v5.

As mentioned in issue 2079, the current (4.7.3) pgo client is not compatible with v5 pg operator (or at least, I couldn't get it working with the current documentation). Version 5 of pg operator does not deploy a svc/postgres-operator, so it's not possible for the pgo client to connect via the pgo api-server using the port-forward described in the documentation.

That said, as PGO manages the networking for Postgres clusters (and as such, manages listen_adresses), there's no reason to modify the listen_addresses configuration parameter. If you need to manage networking or networking access, you can do that by setting the pg_hba config or using NetworkPolicies.

Yeah, I wondered about that - it makes more sense that pgo manages it via Kubernetes networking, but since the documentation specifically addresses listen_addresses, I thought that it is still relevant.

[jkatz]

There is currently no pgo client equivalent in v5. Is there a reason you are looking for one?

All of the things that you can do with the pgo client (and more) are possible in v5 through manipulation of the custom resource manifest. Much of this is covered in the v5 tutorial. The quickstart even covers an example of setting up a port-forward to a Postgres cluster.