Bug Report deploy PgBouncer 1.24 in EDB image version 17.7 for CNP Operator 1.28

[kallol2909]

While deploy pgbouncer in Cloud native PG for EDB , I am getting below error
kubectl logs pod/eoc-pooler-768cf5d49f-z49jj -n eocdb-cck
Defaulted container "pgbouncer" out of: pgbouncer, bootstrap-controller (init)

{"level":"info","ts":"2026-01-02T09:06:07.8442399Z","msg":"Starting EDB Postgres for Kubernetes PgBouncer Instance Manager","logger":"pgbouncer-manager","version":"1.28.0","build":{"Version":"1.28.0","Commit":"d2b15b5dd","Date":"2025-12-16"}}

{"level":"error","ts":"2026-01-02T09:06:07.8602401Z","msg":"Error while running manager","logger":"pgbouncer-manager","error":"while initializing reconciler: while reading secrets: while getting client TLS secret: resource name may not be empty","stacktrace":"github.com/cloudnative-pg/machinery/pkg/log.(*logger).Error\n\tpkg/mod/github.com/cloudnative-pg/machinery@v0.3.1/pkg/log/log.go:125\ngithub.com/EnterpriseDB/cloud-native-postgres/internal/cmd/manager/pgbouncer/run.NewCmd.func2\n\tinternal/cmd/manager/pgbouncer/run/cmd.go:78\ngithub.com/spf13/cobra.(*Command).execute\n\tpkg/mod/github.com/spf13/cobra@v1.10.1/command.go:1015\ngithub.com/spf13/cobra.(*Command).Execute\n\tpkg/mod/github.com/spf13/cobra@v1.10.1/command.go:1148\ngithub.com/spf13/cobra.(*Command).Execute\n\tpkg/mod/github.com/spf13/cobra@v1.10.1/command.go:1071\nmain.main\n\tcmd/manager/main.go:75\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:285"}

I am not defining any certificate either in DB cluster or PgBouncer yaml, how to resolve the issue

[dosubot]

Hi @kallol2909! I'm Dosu and I’m helping the charts team.

This error happens because PgBouncer expects a client TLS secret, and CloudNativePG 1.28.0 changed how it handles certificate references. If you don't define certificates in your DB cluster or Pooler YAML, PgBouncer tries to reuse the cluster's certificates, but a stale or missing value can trigger the "resource name may not be empty" error. TLS is required for PgBouncer in CloudNativePG—there's no supported way to disable it or run without certificates docs.

To resolve this, patch the Pooler resource to remove the stale serverTLS status field and restart the deployment:

kubectl patch pooler -n <your_namespace> <pooler_name> --type=json \
  -p='[{"op": "remove", "path": "/status/secrets/serverTLS"}]' --subresource=status

kubectl rollout restart deployment -n <your_namespace> <pooler_name>

Alternatively, delete and redeploy the Pooler resource to re-initialize certificates source.

If you use custom TLS secrets, you must manually create the cnpg_pooler_pgbouncer role and authentication function in PostgreSQL docs. If the error persists, double-check your manifests and secret references.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[kallol2909]

Hi @dosu

Thanks for your quick response on the issue. I have done the changes you have mentioned, but still I am getting same error. Actually, when I am doing rolleout restart or delete the pod, again it is creating the server TLS, what I am expecting.
Can you please provide me yaml for pgbouncer, where I can define the server yaml details and making it null

[dosubot]

There isn't a way to set the server TLS details to null in the PgBouncer Pooler YAML for CloudNativePG. TLS is required and managed automatically—by default, PgBouncer reuses the certificates from the associated PostgreSQL cluster. The Pooler spec does not expose any field to disable TLS or set the secret to null. If you want to use custom TLS certificates, you must provide a valid Kubernetes secret with the required keys (tls.crt and tls.key), but you cannot disable TLS or make it optional in the manifest.

Here's a canonical Pooler YAML example (note the absence of any TLS field):

apiVersion: postgresql.cnpg.io/v1
kind: Pooler
metadata:
  name: pooler-example
spec:
  cluster:
    name: cluster-example
  instances: 3
  type: rw
  pgbouncer:
    poolMode: session
    parameters:
      max_client_conn: "1000"
      default_pool_size: "10"

If you omit TLS configuration, CloudNativePG will always try to reuse the cluster's certificates. If you see errors like "resource name may not be empty," it usually means the cluster's certificates are missing or misconfigured, or there is a stale status field in the Pooler resource. Double-check your cluster's certificate setup and ensure there are no leftover or invalid references in the Pooler status.

More details: CloudNativePG connection pooling docs

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[kallol2909]

Hi @dosu
Thank you for your quick support.
I am not configuring any certificate which creating the DB cluster . But I can see by default some certificates are getting created. Is there any way to disable the certificates in cluster level ?
kubectl get clusters.postgresql.k8s.enterprisedb.io eocdb-cck -n eocdb-cck -o yaml | grep -i tls
ssl_max_protocol_version: TLSv1.3
ssl_min_protocol_version: TLSv1.3
replicationTLSSecret: eocdb-cck-replication
serverTLSSecret: eocdb-cck-server

[dosubot]

There is no way to disable certificate (TLS) creation at the cluster level in CloudNativePG. TLS is always required for secure connections, and the operator will automatically generate and manage the necessary secrets (like serverTLSSecret and replicationTLSSecret) for every cluster—even if you don't specify any certificate configuration. This is by design for security and best practices in Kubernetes environments. You can provide your own certificates if you need more control, but you cannot turn off TLS or certificate management entirely. More details are in the official documentation on certificates and operator capability levels.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[kallol2909]

kubectl get pooler -n eocdb-cck -o yaml | grep -i tls
serverTLS: {}
kubectl get secrets -n eocdb-cck | grep db
eocdb-cck-app kubernetes.io/basic-auth 11 9d
eocdb-cck-ca Opaque 2 9d
eocdb-cck-pooler kubernetes.io/tls 2 9d
eocdb-cck-pooler-auth Opaque 2 6d21h
eocdb-cck-pull kubernetes.io/dockerconfigjson 1 9d
eocdb-cck-replication kubernetes.io/tls 2 9d
eocdb-cck-server kubernetes.io/tls 2 9d

[kallol2909]

https://cloudnative-pg.io/documentation/current/certificates/
these pages are not opening

[kallol2909]

Hi @dosu
https://cloudnative-pg.io/documentation/current/certificates/ , https://cloudnative-pg.io/documentation/current/operator_capability_levels/ these pages are not opening.

[dosubot]

Those documentation links are currently down, but you can access the same content using versioned URLs. For certificates, see the CloudNativePG 1.27 Certificates documentation. For operator capability levels, use CloudNativePG 1.26 Operator Capability Levels or 1.25 version.

Quick summary:

• CloudNativePG always requires TLS certificates for clusters. The operator manages these automatically unless you provide your own secrets. There’s no supported way to disable TLS or certificate management at the cluster level. You can use your own certificates by specifying secrets, but the operator will still expect all required secrets to exist and be valid. See certificate management details.

• Operator capability levels describe the features CloudNativePG provides, from Level 1 (Basic install) up to Level 5 (Auto pilot). These cover installation, seamless upgrades, full lifecycle management (including HA, backups, and pooling), deep observability, and automated failover/self-healing. See capability levels breakdown.

Let me know if you need a YAML example or more details from these docs.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[kallol2909]

Hi @dosu
Thanks for your response.
Can you please provide the yaml for pgb and steps to install it.

I am downgrading the operator to 1.27, at least I can install the pgbouncer. But our application is not working here, so I had tried to upgrade it , due to the same certificate related reason. Can you please provide , if there is any way to disable the certificate in 1.27 ?

[dosubot]

Here's a canonical YAML for deploying PgBouncer (Pooler) in CloudNativePG 1.27:

apiVersion: postgresql.cnpg.io/v1
kind: Pooler
metadata:
  name: pooler-example
spec:
  cluster:
    name: cluster-example
  instances: 3
  type: rw
  pgbouncer:
    poolMode: session
    parameters:
      max_client_conn: "1000"
      default_pool_size: "10"

Steps to install PgBouncer in 1.27:

1. Make sure your PostgreSQL cluster is running in the same namespace.
2. Apply the Pooler YAML above (edit cluster-example to match your cluster name).
3. Wait for the Pooler deployment and service to become ready (kubectl get deployment,svc -n <namespace>).
4. Connect your application to the Pooler service (e.g., pooler-example-rw).

Important:
TLS/certificates cannot be disabled in CloudNativePG 1.27. The operator always manages and requires TLS for secure connections, and PgBouncer will reuse the cluster's certificates by default. There is no supported way to turn off certificate management or set TLS to null in the YAML. If you provide your own secrets, you must manually create the cnpg_pooler_pgbouncer role and authentication function in each database (docs).

If your application isn't working after downgrade, check for certificate mismatches, stale secrets, or permission issues. Restarting pods after secret changes and verifying the cnpg_pooler_pgbouncer user/function setup can help resolve most issues (troubleshooting).

For more details, see the CloudNativePG 1.27 connection pooling docs.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[kallol2909]

Hi @dosu
Thank you for your help. I have already done the same way, and pgbouner is running for operator 1.27. Our application team is working for the installation and integration. Will let you know the status .
Note: I am using EDB CNP operator and EDB 17.7 DB image , not the open source CNPG

[dosubot]

You're welcome! Glad to hear PgBouncer is running with operator 1.27. Most guidance for CloudNativePG applies to the EDB CNP operator and EDB 17.7 image, but if you run into any EDB-specific issues or differences during integration, just share the details and I can help troubleshoot or clarify. Let me know how the application integration goes or if you need anything else!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}