Merge pull request #5895 from EnterpriseDB/automatic_docs_update/repo…

…_EnterpriseDB/cloud-native-postgres/ref_refs/tags/v1.23.3

product_docs/docs/postgres_for_kubernetes/1/before_you_start.mdx

@@ -76,7 +76,7 @@ specific to Kubernetes and PostgreSQL.
 : `kubectl` is the command-line tool used to manage a Kubernetes cluster.
 
 EDB Postgres for Kubernetes requires a Kubernetes version supported by the community. Please refer to the
-[Supported releases](https://www.enterprisedb.com/resources/platform-compatibility#pgk8s) page for details.
+["Supported releases"](https://www.enterprisedb.com/resources/platform-compatibility#pgk8s) page for details.
 
 ## PostgreSQL terminology
 

product_docs/docs/postgres_for_kubernetes/1/bootstrap.mdx

@@ -628,8 +628,15 @@ from a live cluster, just like the case of `initdb` and  `recovery` bootstrap me
 If the new cluster is created as a replica cluster (with replica mode enabled), application
 database configuration will be skipped.
 
-The following example configure the application database `app` with password in
-supplied secret `app-secret` after bootstrap from a live cluster.
+!!! Important
+    While the `Cluster` is in recovery mode, no changes to the database,
+    including the catalog, are permitted. This restriction includes any role
+    overrides, which are deferred until the `Cluster` transitions to primary.
+    During the recovery phase, roles remain as defined in the source cluster.
+
+The example below configures the `app` database with the owner `app` and
+the password stored in the provided secret `app-secret`, following the
+bootstrap from a live cluster.
 
 ```yaml
 apiVersion: postgresql.k8s.enterprisedb.io/v1
@@ -645,19 +652,16 @@ spec:
       source: cluster-example
 ```
 
-With the above configuration, the following will happen after recovery is completed:
+With the above configuration, the following will happen only **after recovery is
+completed**:
 
-1.  if database `app` does not exist, a new database `app` will be created.
-2.  if user `app` does not exist, a new user `app` will be created.
-3.  if user `app` is not the owner of database, user `app` will be granted
-    as owner of database `app`.
-4.  If value of `username` match value of `owner` in secret, the password of
-    application database will be changed to the value of `password` in secret.
-
-!!! Important
-    For a replica cluster with replica mode enabled, the operator will not
-    create any database or user in the PostgreSQL instance, as these will be
-    recovered from the original cluster.
+1.  If the `app` database does not exist, it will be created.
+2.  If the `app` user does not exist, it will be created.
+3.  If the `app` user is not the owner of the `app` database, ownership will be
+    granted to the `app` user.
+4.  If the `username` value matches the `owner` value in the secret, the
+    password for the application user (the `app` user in this case) will be
+    updated to the `password` value in the secret.
 
 #### Current limitations
 

product_docs/docs/postgres_for_kubernetes/1/connection_pooling.mdx

@@ -89,6 +89,11 @@ deletion of the pooler, and vice versa.
     possible architectures. You can have clusters without poolers, clusters with
     a single pooler, or clusters with several poolers, that is, one per application.
 
+!!! Important
+    When the operator is upgraded, the pooler pods will undergo a rolling
+    upgrade. This is necessary to ensure that the instance manager within the
+    pooler pods is also upgraded.
+
 ## Security
 
 Any PgBouncer pooler is transparently integrated with EDB Postgres for Kubernetes support for
@@ -286,6 +291,20 @@ spec:
       default_pool_size: "10"
 ```
 
+The operator by default adds a `ServicePort` with the following data:
+
+```
+  ports:
+  - name: pgbouncer
+    port: 5432
+    protocol: TCP
+    targetPort: pgbouncer
+```
+
+!!! Warning
+    Specifying a `ServicePort` with the name `pgbouncer` or the port `5432`  will prevent the default `ServicePort` from being added.
+    This because `ServicePort` entries with the same `name` or `port` are not allowed on Kubernetes and result in errors.
+
 ## High availability (HA)
 
 Because of Kubernetes' deployments, you can configure your pooler to run on a

product_docs/docs/postgres_for_kubernetes/1/container_images.mdx

@@ -41,7 +41,7 @@ EDB provides and supports
 for EDB Postgres for Kubernetes, and publishes them on
 [quay.io](https://quay.io/enterprisedb/postgresql).
 
-## Image tag requirements
+## Image Tag Requirements
 
 To ensure the operator makes informed decisions, it must accurately detect the
 PostgreSQL major version. This detection can occur in two ways:

product_docs/docs/postgres_for_kubernetes/1/default-monitoring.yaml

@@ -83,6 +83,7 @@ data:
           , pg_catalog.age(datfrozenxid) AS xid_age
           , pg_catalog.mxid_age(datminmxid) AS mxid_age
         FROM pg_catalog.pg_database
+        WHERE datallowconn
       metrics:
         - datname:
             usage: "LABEL"
@@ -247,6 +248,71 @@ data:
             usage: "COUNTER"
             description: "Number of buffers allocated"
 
+    pg_stat_bgwriter_17:
+      runonserver: ">=17.0.0"
+      name: pg_stat_bgwriter
+      query: |
+        SELECT buffers_clean
+          , maxwritten_clean
+          , buffers_alloc
+          , EXTRACT(EPOCH FROM stats_reset) AS stats_reset_time
+        FROM pg_catalog.pg_stat_bgwriter
+      metrics:
+        - buffers_clean:
+            usage: "COUNTER"
+            description: "Number of buffers written by the background writer"
+        - maxwritten_clean:
+            usage: "COUNTER"
+            description: "Number of times the background writer stopped a cleaning scan because it had written too many buffers"
+        - buffers_alloc:
+            usage: "COUNTER"
+            description: "Number of buffers allocated"
+        - stats_reset_time:
+            usage: "GAUGE"
+            description: "Time at which these statistics were last reset"
+
+    pg_stat_checkpointer:
+      runonserver: ">=17.0.0"
+      query: |
+        SELECT num_timed AS checkpoints_timed
+          , num_requested AS checkpoints_req
+          , restartpoints_timed
+          , restartpoints_req
+          , restartpoints_done
+          , write_time
+          , sync_time
+          , buffers_written
+          , EXTRACT(EPOCH FROM stats_reset) AS stats_reset_time
+        FROM pg_catalog.pg_stat_checkpointer
+      metrics:
+        - checkpoints_timed:
+            usage: "COUNTER"
+            description: "Number of scheduled checkpoints that have been performed"
+        - checkpoints_req:
+            usage: "COUNTER"
+            description: "Number of requested checkpoints that have been performed"
+        - restartpoints_timed:
+            usage: "COUNTER"
+            description: "Number of scheduled restartpoints due to timeout or after a failed attempt to perform it"
+        - restartpoints_req:
+            usage: "COUNTER"
+            description: "Number of requested restartpoints that have been performed"
+        - restartpoints_done:
+            usage: "COUNTER"
+            description: "Number of restartpoints that have been performed"
+        - write_time:
+            usage: "COUNTER"
+            description: "Total amount of time that has been spent in the portion of processing checkpoints and restartpoints where files are written to disk, in milliseconds"
+        - sync_time:
+            usage: "COUNTER"
+            description: "Total amount of time that has been spent in the portion of processing checkpoints and restartpoints where files are synchronized to disk, in milliseconds"
+        - buffers_written:
+            usage: "COUNTER"
+            description: "Number of buffers written during checkpoints and restartpoints"
+        - stats_reset_time:
+            usage: "GAUGE"
+            description: "Time at which these statistics were last reset"
+
     pg_stat_database:
       query: |
         SELECT datname

product_docs/docs/postgres_for_kubernetes/1/index.mdx

@@ -181,9 +181,9 @@ The following versions of Postgres are currently supported:
 -   EDB Postgres Extended: 12 - 16
 
 PostgreSQL and EDB Postgres Advanced are available on the following platforms:
-`linux/amd64`, `linux/ppc64le`, `linux/s390x`.  
-In addition, PostgreSQL is also supported on `linux/arm64`.  
-EDB Postgres Extended is supported only on `linux/amd64`.  
+`linux/amd64`, `linux/ppc64le`, `linux/s390x`. \\
+In addition, PostgreSQL is also supported on `linux/arm64`. \\
+EDB Postgres Extended is supported only on `linux/amd64`. \\
 EDB supports operand images for `linux/ppc64le` and `linux/s390x` architectures
 on OpenShift only.
 

product_docs/docs/postgres_for_kubernetes/1/installation_upgrade.mdx

@@ -23,12 +23,12 @@ The operator can be installed using the provided [Helm chart](https://github.com
 The operator can be installed like any other resource in Kubernetes,
 through a YAML manifest applied via `kubectl`.
 
-You can install the [latest operator manifest](https://get.enterprisedb.io/cnp/postgresql-operator-1.23.2.yaml)
+You can install the [latest operator manifest](https://get.enterprisedb.io/cnp/postgresql-operator-1.23.3.yaml)
 for this minor release as follows:
 
 ```sh
 kubectl apply --server-side -f \
-  https://get.enterprisedb.io/cnp/postgresql-operator-1.23.2.yaml
+  https://get.enterprisedb.io/cnp/postgresql-operator-1.23.3.yaml
 ```
 
 You can verify that with:

product_docs/docs/postgres_for_kubernetes/1/labels_annotations.mdx

@@ -171,16 +171,20 @@ These predefined annotations are managed by EDB Postgres for Kubernetes.
 :   Current status of the PVC: `initializing`, `ready`, or `detached`.
 
 `k8s.enterprisedb.io/reconcilePodSpec`
-:   When set to `disabled` on a `Cluster`, the operator prevents instances
-   from being restarted in case of drift in the PodSpec.
-   PodSpec drift could be due, for example, to:
+:  Annotation can be applied to a `Cluster` or `Pooler` to prevent restarts.
+
+   When set to `disabled` on a `Cluster`, the operator prevents instances
+   from restarting due to changes in the PodSpec. This includes changes to:
 
 ```
- - Changes to topology or affinity
- - Change of scheduler
- - Change to volumes or containers
+ - Topology or affinity
+ - Scheduler
+ - Volumes or containers
 ```
 
+  When set to `disabled` on a `Pooler`, the operator restricts any modifications
+  to the deployment specification, except for changes to `spec.instances`.
+
 `k8s.enterprisedb.io/reconciliationLoop`
 :   When set to `disabled` on a `Cluster`, the operator prevents the
     reconciliation loop from running.

product_docs/docs/postgres_for_kubernetes/1/logging.mdx

@@ -17,15 +17,13 @@ Each log entry has the following fields:
 -   `logging_podName` – The pod where the log was created.
 
 !!! Warning
-
     Long-term storage and management of logs is outside the operator's purview,
     and needs to be provided at the level of the Kubernetes installation.
     See the
     [Kubernetes Logging Architecture](https://kubernetes.io/docs/concepts/cluster-administration/logging/)
     documentation.
 
 !!! Info
-
     If your log ingestion system requires it, you can rename the `level` and `ts` field names using the `log-field-level` and
     `log-field-timestamp` flags of the operator controller. Edit the `Deployment` definition of the
     `cloudnative-pg` operator.
@@ -93,7 +91,6 @@ To enable this support, add the required `pgaudit` parameters to the `postgresql
 section in the configuration of the cluster.
 
 !!! Important
-
     You need to add the PGAudit library to `shared_preload_libraries`.
     EDB Postgres for Kubernetes adds the library based on the
     presence of `pgaudit.*` parameters in the postgresql configuration.
@@ -104,7 +101,6 @@ The operator also takes care of creating and removing the extension from all
 the available databases in the cluster.
 
 !!! Important
-
     EDB Postgres for Kubernetes runs the `CREATE EXTENSION` and
     `DROP EXTENSION` commands in all databases in the cluster that accept
     connections.

product_docs/docs/postgres_for_kubernetes/1/monitoring.mdx

@@ -542,6 +542,7 @@ Every custom query has the following basic structure:
 Here is a short description of all the available fields:
 
 -   `<MetricName>`: the name of the Prometheus metric
+    -   `name`: override `<MetricName>`, if defined
     -   `query`: the SQL query to run on the target database to generate the metrics
     -   `primary`: whether to run the query only on the primary instance
     -   `master`: same as `primary` (for compatibility with the Prometheus PostgreSQL exporter's syntax - deprecated) 
@@ -552,6 +553,7 @@ Here is a short description of all the available fields:
         to enable auto discovery. Overwrites the default database if provided.
     -   `metrics`: section containing a list of all exported columns, defined as follows:
         -   `<ColumnName>`: the name of the column returned by the query
+            -   `name`: override the `ColumnName` of the column in the metric, if defined
             -   `usage`: one of the values described below
             -   `description`: the metric's description
             -   `metrics_mapping`: the optional column mapping when `usage` is set to `MAPPEDMETRIC`