Merge remote-tracking branch 'public/develop' into develop

Author: edb-slonik

product_docs/docs/postgres_for_kubernetes/1/backup_barmanobjectstore.mdx

@@ -29,7 +29,7 @@ be *tarballs*. Both base backups and WAL files can be compressed
 and encrypted.
 
 For this, it is required to use an image with `barman-cli-cloud` included.
-You can use the image `quay.io/enterprisedb/postgresql` for this scope,
+You can use the image `docker.enterprisedb.com/k8s_enterprise/postgresql` for this scope,
 as it is composed of a community PostgreSQL image and the latest
 `barman-cli-cloud` package.
 
@@ -38,6 +38,15 @@ as it is composed of a community PostgreSQL image and the latest
     in your system to take advantage of the improvements introduced in
     Barman cloud (as well as improve the security aspects of your cluster).
 
+!!! Warning "Changes in Barman Cloud 3.16+ and Bucket Creation"
+    Starting with Barman Cloud 3.16, most Barman Cloud commands no longer
+    automatically create the target bucket, assuming it already exists. Only the
+    `barman-cloud-check-wal-archive` command creates the bucket now. Whenever this
+    is not the first operation run on an empty bucket, {{name.ln}} will throw an
+    error. As a result, to ensure reliable, future-proof operations and avoid
+    potential issues, we strongly recommend that you create and configure your
+    object store bucket *before* creating a `Cluster` resource that references it.
+
 A backup is performed from a primary or a designated primary instance in a
 `Cluster` (please refer to
 [replica clusters](replica_cluster.md)

product_docs/docs/postgres_for_kubernetes/1/bootstrap.mdx

@@ -626,7 +626,7 @@ file on the source PostgreSQL instance:
 host replication streaming_replica all md5
 ```
 
-The following manifest creates a new PostgreSQL 17.5 cluster,
+The following manifest creates a new PostgreSQL 18.0 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`
@@ -641,7 +641,7 @@ metadata:
   name: target-db
 spec:
   instances: 3
-  imageName: quay.io/enterprisedb/postgresql:17.5
+  imageName: docker.enterprisedb.com/k8s_enterprise/postgresql:18.0-system-trixie
 
   bootstrap:
     pg_basebackup:
@@ -661,7 +661,7 @@ spec:
 ```
 
 All the requirements must be met for the clone operation to work, including
-the same PostgreSQL version (in our case 17.5).
+the same PostgreSQL version (in our case 18.0).
 
 #### TLS certificate authentication
 
@@ -676,7 +676,7 @@ in the same Kubernetes cluster.
     This example can be easily adapted to cover an instance that resides
     outside the Kubernetes cluster.
 
-The manifest defines a new PostgreSQL 17.5 cluster called `cluster-clone-tls`,
+The manifest defines a new PostgreSQL 18.0 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
@@ -691,7 +691,7 @@ metadata:
   name: cluster-clone-tls
 spec:
   instances: 3
-  imageName: quay.io/enterprisedb/postgresql:17.5
+  imageName: docker.enterprisedb.com/k8s_enterprise/postgresql:18.0-system-trixie
 
   bootstrap:
     pg_basebackup:

product_docs/docs/postgres_for_kubernetes/1/cncf-projects/external-secrets.mdx

@@ -94,7 +94,7 @@ uses a `Merge` policy to update only the specified fields (`password`, `pgpass`,
 `jdbc-uri` and `uri`) in the `cluster-example-app` secret.
 
 ```yaml
-apiVersion: external-secrets.io/v1beta1
+apiVersion: external-secrets.io/v1
 kind: ExternalSecret
 metadata:
   name: cluster-example-app-secret
@@ -182,7 +182,7 @@ named `vault-token` exists in the same namespace, containing the token used to
 authenticate with Vault.
 
 ```yaml
-apiVersion: external-secrets.io/v1beta1
+apiVersion: external-secrets.io/v1
 kind: SecretStore
 metadata:
   name: vault-backend

product_docs/docs/postgres_for_kubernetes/1/connection_pooling.mdx

@@ -335,11 +335,13 @@ These are the PgBouncer options you can customize, with links to the PgBouncer
 documentation for each parameter. Unless stated otherwise, the default values
 are the ones directly set by PgBouncer.
 
+-   [`auth_type`](https://www.pgbouncer.org/config.html#auth_type)
 -   [`application_name_add_host`](https://www.pgbouncer.org/config.html#application_name_add_host)
 -   [`autodb_idle_timeout`](https://www.pgbouncer.org/config.html#autodb_idle_timeout)
 -   [`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_sslmode`](https://www.pgbouncer.org/config.html#client_tls_sslmode)
 -   [`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)
@@ -378,6 +380,7 @@ are the ones directly set by PgBouncer.
 -   [`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_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)
 -   [`suspend_timeout`](https://www.pgbouncer.org/config.html#suspend_timeout)
 -   [`tcp_defer_accept`](https://www.pgbouncer.org/config.html#tcp_defer_accept)
@@ -587,18 +590,10 @@ cnp_pgbouncer_stats_total_xact_time{database="pgbouncer"} 0
     For a better understanding of the metrics please refer to the PgBouncer documentation.
 
 As for clusters, a specific pooler can be monitored using the
-[Prometheus operator's](https://github.com/prometheus-operator/prometheus-operator) resource
-[PodMonitor](https://github.com/prometheus-operator/prometheus-operator/blob/v0.47.1/Documentation/api.md#podmonitor).
-A `PodMonitor` correctly pointing to a pooler can be created by the operator by setting
-`.spec.monitoring.enablePodMonitor` to `true` in the `Pooler` resource. The default is `false`.
+[Prometheus operator's](https://github.com/prometheus-operator/prometheus-operator)
+[`PodMonitor` resource](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api-reference/api.md#monitoring.coreos.com/v1.PodMonitor).
 
-!!! Important
-    Any change to `PodMonitor` created automatically is overridden by the
-    operator at the next reconciliation cycle. If you need to customize it, you can
-    do so as shown in the following example.
-
-To deploy a `PodMonitor` for a specific pooler manually, you can define it as
-follows and change it as needed:
+You can deploy a `PodMonitor` for a specific pooler using the following basic example, and change it as needed:
 
 ```yaml
 apiVersion: monitoring.coreos.com/v1
@@ -613,6 +608,18 @@ spec:
   - port: metrics
 ```
 
+### Deprecation of Automatic `PodMonitor` Creation
+
+!!!warning "Feature Deprecation Notice"
+    The `.spec.monitoring.enablePodMonitor` field in the `Pooler` resource is
+    now deprecated and will be removed in a future version of the operator.
+
+If you are currently using this feature, we strongly recommend you either
+remove or set `.spec.monitoring.enablePodMonitor` to `false` and manually
+create a `PodMonitor` resource for your pooler as described above.
+This change ensures that you have complete ownership of your monitoring
+configuration, preventing it from being managed or overwritten by the operator.
+
 ## Logging
 
 Logs are directly sent to standard output, in JSON format, like in the

product_docs/docs/postgres_for_kubernetes/1/container_images.mdx

@@ -39,7 +39,7 @@ automatically overrides it with its instance manager.
 EDB provides and maintains
 [public PostgreSQL container images](https://github.com/enterprisedb/docker-postgres)
 that are fully compatible with {{name.ln}}. These images are published on
-[quay.io](https://quay.io/enterprisedb/postgresql).
+[docker.enterprisedb.com](https://docker.enterprisedb.com/k8s_enterprise/postgresql).
 
 ## Image Tag Requirements
 
@@ -70,4 +70,4 @@ Examples of accepted image tags:
     `latest` is not considered a valid tag for the image.
 
 !!! Note
-    Image tag requirements do no apply for images defined in a catalog.
+    Image tag requirements do not apply for images defined in a catalog.

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:  quay.io/enterprisedb/postgresql:17.5
+PostgreSQL Image:  docker.enterprisedb.com/k8s_enterprise/postgresql:18.0-system-trixie
 Primary instance:  cluster-example-2
 Status:            Cluster in healthy state 
 Instances:         3

product_docs/docs/postgres_for_kubernetes/1/image_catalog.mdx

@@ -35,11 +35,13 @@ metadata:
 spec:
   images:
     - major: 15
-      image: quay.io/enterprisedb/postgresql:15.6
+      image: docker.enterprisedb.com/k8s_enterprise/postgresql:15.14-system-trixie
     - major: 16
-      image: quay.io/enterprisedb/postgresql:16.8
+      image: docker.enterprisedb.com/k8s_enterprise/postgresql:16.10-system-trixie
     - major: 17
-      image: quay.io/enterprisedb/postgresql:17.5
+      image: docker.enterprisedb.com/k8s_enterprise/postgresql:17.6-system-trixie
+    - major: 18
+      image: docker.enterprisedb.com/k8s_enterprise/postgresql:18.0-system-trixie
 ```
 
 **Example of a Cluster-Wide Catalog using `ClusterImageCatalog` Resource:**
@@ -52,15 +54,18 @@ metadata:
 spec:
   images:
     - major: 15
-      image: quay.io/enterprisedb/postgresql:15.6
+      image: docker.enterprisedb.com/k8s_enterprise/postgresql:15.14-system-trixie
     - major: 16
-      image: quay.io/enterprisedb/postgresql:16.8
+      image: docker.enterprisedb.com/k8s_enterprise/postgresql:16.10-system-trixie
     - major: 17
-      image: quay.io/enterprisedb/postgresql:17.5
+      image: docker.enterprisedb.com/k8s_enterprise/postgresql:17.6-system-trixie
+    - major: 18
+      image: docker.enterprisedb.com/k8s_enterprise/postgresql:18.0-system-trixie
 ```
 
 A `Cluster` resource has the flexibility to reference either an `ImageCatalog`
-or a `ClusterImageCatalog` to precisely specify the desired image.
+(like in the following example) or a `ClusterImageCatalog` to precisely specify
+the desired image.
 
 ```yaml
 apiVersion: postgresql.k8s.enterprisedb.io/v1
@@ -71,6 +76,7 @@ spec:
   instances: 3
   imageCatalogRef:
     apiGroup: postgresql.k8s.enterprisedb.io
+    # Change the following to `ClusterImageCatalog` if needed
     kind: ImageCatalog
     name: postgresql
     major: 16
@@ -84,33 +90,56 @@ Any alterations to the images within a catalog trigger automatic updates for
 
 ## {{name.ln}} Catalogs
 
-The {{name.ln}} project maintains `ClusterImageCatalogs` for the images it
-provides. These catalogs are regularly updated with the latest images for each
-major version. By applying the `ClusterImageCatalog.yaml` file from the
-{{name.ln}} project's GitHub repositories, cluster administrators can ensure
-that their clusters are automatically updated to the latest version within the
-specified major release.
+The {{name.ln}} project maintains `ClusterImageCatalog` manifests for all
+supported images.
 
-### PostgreSQL Container Images
+These catalogs are regularly updated and published in the
+[artifacts repository](https://github.com/cloudnative-pg/artifacts/tree/main/image-catalogs).
 
-You can install the
-[latest version of the cluster catalog for the PostgreSQL Container Images](https://raw.githubusercontent.com/cloudnative-pg/postgres-containers/main/Debian/ClusterImageCatalog-bookworm.yaml)
-([cloudnative-pg/postgres-containers](https://github.com/enterprisedb/docker-postgres) repository)
-with:
+Each catalog corresponds to a specific combination of image type (e.g.
+`minimal`) and Debian release (e.g. `trixie`). It lists the most up-to-date
+container images for every supported PostgreSQL major version.
+
+By installing these catalogs, cluster administrators can ensure that their
+PostgreSQL clusters are automatically updated to the latest patch release
+within a given PostgreSQL major version, for the selected Debian distribution
+and image type.
+
+For example, to install the latest catalog for the `minimal` PostgreSQL
+container images on Debian `trixie`, run:
 
 ```shell
-kubectl apply \
-  -f https://raw.githubusercontent.com/cloudnative-pg/postgres-containers/main/Debian/ClusterImageCatalog-bookworm.yaml
+kubectl apply -f \
+  https://raw.githubusercontent.com/cloudnative-pg/artifacts/refs/heads/main/image-catalogs/catalog-minimal-trixie.yaml
 ```
 
-### PostGIS Container Images
+You can install all the available catalogs by using the `kustomization` file
+present in the `image-catalogs` directory:
+
+```shell
+kubectl apply -k https://github.com/cloudnative-pg/artifacts//image-catalogs?ref=main
+```
 
-You can install the
-[latest version of the cluster catalog for the PostGIS Container Images](https://raw.githubusercontent.com/cloudnative-pg/postgis-containers/main/PostGIS/ClusterImageCatalog.yaml)
-([cloudnative-pg/postgis-containers](https://github.com/cloudnative-pg/postgis-containers) repository)
-with:
+You can then view all the catalogs deployed with:
 
 ```shell
-kubectl apply \
-  -f https://raw.githubusercontent.com/cloudnative-pg/postgis-containers/main/PostGIS/ClusterImageCatalog.yaml
+kubectl get clusterimagecatalogs.postgresql.k8s.enterprisedb.io
+```
+
+For example, you can create a cluster with the latest `minimal` image for PostgreSQL 18 on `trixie` with:
+
+```yaml
+apiVersion: postgresql.k8s.enterprisedb.io/v1
+kind: Cluster
+metadata:
+  name: angus
+spec:
+  instances: 3
+  imageCatalogRef:
+    apiGroup: postgresql.k8s.enterprisedb.io
+    kind: ClusterImageCatalog
+    name: postgresql-minimal-trixie
+    major: 18
+  storage:
+    size: 1Gi
 ```

product_docs/docs/postgres_for_kubernetes/1/imagevolume_extensions.mdx

@@ -302,7 +302,7 @@ spec:
 ```
 
 {{name.ln}} will set the `LD_LIBRARY_PATH` environment variable to include
-`/extensions/postgis/system`, allowing PostgreSQL to locate and load these
+`/extensions/postgis/syslib`, allowing PostgreSQL to locate and load these
 system libraries at runtime.
 
 !!! Important
@@ -316,10 +316,10 @@ system libraries at runtime.
 A standard extension container image for {{name.ln}} includes two
 required directories at its root:
 
--   `share`: contains the extension control file (e.g., `<EXTENSION>.control`)
-    and any SQL files.
--   `lib`: contains the extension's shared library (e.g., `<EXTENSION>.so`) and
-    any additional required libraries.
+-   `/share/`: contains an `extension` subdirectory with the extension control
+    file (e.g. `<EXTENSION>.control`) and the corresponding SQL files.
+-   `/lib/`: contains the extension’s shared library (e.g. `<EXTENSION>.so`) as
+    well as any other required libraries.
 
 Following this structure ensures that the extension will be automatically
 discoverable and usable by PostgreSQL within {{name.ln}} without requiring

product_docs/docs/postgres_for_kubernetes/1/index.mdx

@@ -4,7 +4,7 @@ description: The {{name.ln}} operator is a fork based on CloudNativePG™ which
 originalFilePath: src/index.md
 indexCards: none
 directoryDefaults:
-  version: "1.27.0"
+  version: "1.27.1"
 redirects:
   - /postgres_for_kubernetes/preview/:splat
 navigation: