Process changes to docs from: repo: EnterpriseDB/cloud-native-postgres ref: refs/tags/v1.29.0

product_docs/docs/postgres_for_kubernetes/1/bootstrap.mdx

@@ -647,7 +647,7 @@ file on the source PostgreSQL instance:
 host replication streaming_replica all md5
 ```
 
-The following manifest creates a new PostgreSQL 18.1 cluster,
+The following manifest creates a new PostgreSQL 18.3 cluster,
 called `target-db`, using the `pg_basebackup` bootstrap method
 to clone an external PostgreSQL cluster defined as `source-db`
 (in the `externalClusters` array). As you can see, the `source-db`
@@ -662,7 +662,7 @@ metadata:
   name: target-db
 spec:
   instances: 3
-  imageName: docker.enterprisedb.com/k8s/postgresql:18.1-standard-ubi9
+  imageName: docker.enterprisedb.com/k8s/postgresql:18.3-standard-ubi9
 
   bootstrap:
     pg_basebackup:
@@ -682,7 +682,7 @@ spec:
 ```
 
 All the requirements must be met for the clone operation to work, including
-the same PostgreSQL version (in our case 18.1).
+the same PostgreSQL version (in our case 18.3).
 
 #### TLS certificate authentication
 
@@ -698,7 +698,7 @@ This example can be easily adapted to cover an instance that resides
 outside the Kubernetes cluster.
 !!!
 
-The manifest defines a new PostgreSQL 18.1 cluster called `cluster-clone-tls`,
+The manifest defines a new PostgreSQL 18.3 cluster called `cluster-clone-tls`,
 which is bootstrapped using the `pg_basebackup` method from the `cluster-example`
 external cluster. The host is identified by the read/write service
 in the same cluster, while the `streaming_replica` user is authenticated
@@ -713,7 +713,7 @@ metadata:
   name: cluster-clone-tls
 spec:
   instances: 3
-  imageName: docker.enterprisedb.com/k8s/postgresql:18.1-standard-ubi9
+  imageName: docker.enterprisedb.com/k8s/postgresql:18.3-standard-ubi9
 
   bootstrap:
     pg_basebackup:

product_docs/docs/postgres_for_kubernetes/1/cluster_conf.mdx

@@ -89,6 +89,12 @@ Use this field only in case of
 
 ## Environment variables
 
+!!!important
+Environment variables reserved for operator usage (names starting with `PG` or
+`CNP_`, plus `POD_NAME`, `NAMESPACE`, and `CLUSTER_NAME`) cannot be set
+through the `env` and `envFrom` fields and are rejected at admission time.
+!!!
+
 You can customize some system behavior using environment variables. One example
 is the `LDAPCONF` variable, which can point to a custom LDAP configuration
 file. Another example is the `TZ` environment variable, which represents the

product_docs/docs/postgres_for_kubernetes/1/cnpg_i.mdx

@@ -39,7 +39,7 @@ CNPG-I is inspired by the Kubernetes
 The operator communicates with registered plugins using **gRPC**, following the
 [CNPG-I protocol](https://github.com/cloudnative-pg/cnpg-i/blob/main/docs/protocol.md).
 
-{{name.ln}} discovers plugins **at startup**. You can register them in one of two ways:
+You can register plugins in one of two ways:
 
 -   Sidecar container – run the plugin inside the operator’s Deployment
 -   Standalone Deployment – run the plugin as a separate workload in the same
@@ -49,7 +49,9 @@ In both cases, the plugin must be packaged as a container image.
 
 ### Sidecar Container
 
-When running as a sidecar, the plugin must expose its gRPC server via a **Unix
+Sidecar plugins are discovered once at operator startup.
+
+The plugin must expose its gRPC server via a **Unix
 domain socket**. This socket must be placed in a directory shared with the
 operator container, mounted at the path set in `PLUGIN_SOCKET_DIR` (default:
 `/plugin`).
@@ -87,11 +89,8 @@ spec:
 Running a plugin as its own Deployment decouples its lifecycle from the
 operator’s and allows independent scaling. In this setup, the plugin exposes a
 TCP gRPC endpoint behind a Service, with **mTLS** for secure communication.
-
-!!!warning
-{{name.ln}} does **not** discover plugins dynamically. If you deploy a new
-plugin, you must **restart the operator** to detect it.
-!!!
+Standalone plugins are discovered dynamically by watching for Services with the
+required labels and annotations — no operator restart is needed.
 
 Example Deployment:
 

product_docs/docs/postgres_for_kubernetes/1/connection_pooling.mdx

@@ -379,8 +379,9 @@ The operator manages most of the [configuration options for PgBouncer](https://w
 allowing you to modify only a subset of them.
 
 !!!warning
-You are responsible for correctly setting the value of each option, as the
-operator doesn't validate them.
+The operator passes these settings directly to PgBouncer without validation.
+To prevent configuration errors or crash loops, ensure each parameter is
+supported by your specific PgBouncer image version.
 !!!
 
 These are the PgBouncer options you can customize, with links to the PgBouncer
@@ -393,7 +394,9 @@ are the ones directly set by PgBouncer.
 -   [`cancel_wait_timeout`](https://www.pgbouncer.org/config.html#cancel_wait_timeout)
 -   [`client_idle_timeout`](https://www.pgbouncer.org/config.html#client_idle_timeout)
 -   [`client_login_timeout`](https://www.pgbouncer.org/config.html#client_login_timeout)
+-   [`client_tls_ciphers`](https://www.pgbouncer.org/config.html#client_tls_ciphers)
 -   [`client_tls_sslmode`](https://www.pgbouncer.org/config.html#client_tls_sslmode)
+-   [`client_tls13_ciphers`](https://www.pgbouncer.org/config.html#client_tls13_ciphers) (1.25+)
 -   [`default_pool_size`](https://www.pgbouncer.org/config.html#default_pool_size)
 -   [`disable_pqexec`](https://www.pgbouncer.org/config.html#disable_pqexec)
 -   [`dns_max_ttl`](https://www.pgbouncer.org/config.html#dns_max_ttl)
@@ -431,6 +434,7 @@ are the ones directly set by PgBouncer.
 -   [`server_reset_query_always`](https://www.pgbouncer.org/config.html#server_reset_query_always)
 -   [`server_round_robin`](https://www.pgbouncer.org/config.html#server_round_robin)
 -   [`server_tls_ciphers`](https://www.pgbouncer.org/config.html#server_tls_ciphers)
+-   [`server_tls13_ciphers`](https://www.pgbouncer.org/config.html#server_tls13_ciphers) (1.25+)
 -   [`server_tls_protocols`](https://www.pgbouncer.org/config.html#server_tls_protocols)
 -   [`server_tls_sslmode`](https://www.pgbouncer.org/config.html#server_tls_sslmode)
 -   [`stats_period`](https://www.pgbouncer.org/config.html#stats_period)

product_docs/docs/postgres_for_kubernetes/1/declarative_hibernation.mdx

@@ -55,7 +55,7 @@ $ kubectl cnp status <cluster-name>
 Cluster Summary
 Name:              cluster-example
 Namespace:         default
-PostgreSQL Image:  docker.enterprisedb.com/k8s/postgresql:18.1-standard-ubi9
+PostgreSQL Image:  docker.enterprisedb.com/k8s/postgresql:18.3-standard-ubi9
 Primary instance:  cluster-example-2
 Status:            Cluster in healthy state 
 Instances:         3

product_docs/docs/postgres_for_kubernetes/1/declarative_role_management.mdx

@@ -177,6 +177,23 @@ stringData:
   password: SCRAM-SHA-256$<iteration count>:<salt>$<StoredKey>:<ServerKey>
 ```
 
+### Safety when transmitting cleartext passwords
+
+While role passwords are safely managed in Kubernetes using Secrets,
+there is still a risk on the PostgreSQL side. If creating/altering a role with
+password, PostgreSQL may print the password as part of the query statement
+in some `postgres` logs, as mentioned in the [PostgreSQL documentation](https://www.postgresql.org/docs/current/sql-createrole.html):
+
+> The password will be transmitted to the server in cleartext, and it might
+> also be logged in the client's command history or the server log
+
+{{name.ln}} adds a safety layer by temporarily suppressing both statement
+logging (`log_statement`) and error statement logging
+(`log_min_error_statement`) for any CREATE or ALTER operation on a role with
+password, thus preventing leakage in both success and failure scenarios.
+The Status section of the cluster does not print the query statement for any
+managed role operation.
+
 ## Unrealizable role configurations
 
 In PostgreSQL, in some cases, commands cannot be honored by the database and

product_docs/docs/postgres_for_kubernetes/1/failure_modes.mdx

@@ -58,8 +58,26 @@ Do not perform manual operations without [professional support](https://cloudnat
 
 ### Disabling Reconciliation
 
-To temporarily disable the reconciliation loop for a PostgreSQL cluster, use
-the `k8s.enterprisedb.io/reconciliationLoop` annotation:
+The `k8s.enterprisedb.io/reconciliationLoop` annotation allows you to temporarily disable
+the reconciliation loop for {{name.ln}} resources. When set to `"disabled"`,
+the operator will stop processing updates for the annotated resource, preventing
+any automated changes or self-healing actions.
+
+Use this annotation **with extreme caution** and only during emergency
+operations.
+
+!!!warning
+This annotation should be removed as soon as the issue is resolved. Leaving
+it in place prevents the operator from managing the annotated resource. On a
+Cluster, this includes self-healing actions and failover.
+!!!
+
+The following resources support this annotation:
+
+-   **Cluster**: Disables reconciliation of the PostgreSQL cluster
+-   **Backup**: Disables reconciliation of backup operations
+
+Example usage:
 
 ```yaml
 metadata:
@@ -69,12 +87,3 @@ metadata:
 spec:
   # ...
 ```
-
-Use this annotation **with extreme caution** and only during emergency
-operations.
-
-!!!warning
-This annotation should be removed as soon as the issue is resolved. Leaving
-it in place prevents the operator from executing self-healing actions,
-including failover.
-!!!