Merge branch 'master' into delete-volume-on-scale-down

docs/reference/cluster_manifest.md

@@ -217,6 +217,12 @@ explanation of `ttl` and `loop_wait` parameters.
   automatically created by Patroni for cluster members and permanent replication
   slots. Optional.
 
+* **synchronous_mode**
+  Patroni `synchronous_mode` parameter value. The default is set to `false`. Optional.
+  
+* **synchronous_mode_strict**
+  Patroni `synchronous_mode_strict` parameter value. Can be used in addition to `synchronous_mode`. The default is set to `false`. Optional.
+  
 ## Postgres container resources
 
 Those parameters define [CPU and memory requests and limits](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/)
@@ -376,10 +382,11 @@ present.
   How many instances of connection pooler to create.
 
 * **schema**
-  Schema to create for credentials lookup function.
+  Database schema to create for credentials lookup function.
 
 * **user**
   User to create for connection pooler to be able to connect to a database.
+  You can also choose a role from the `users` section or a system user role.
 
 * **dockerImage**
   Which docker image to use for connection pooler deployment.

docs/reference/operator_parameters.md

@@ -80,6 +80,12 @@ Those are top-level keys, containing both leaf keys and groups.
   Patroni native Kubernetes support is used. The default is empty (use
   Kubernetes-native DCS).
 
+* **kubernetes_use_configmaps**
+  Select if setup uses endpoints (default), or configmaps to manage leader when
+  DCS is kubernetes (not etcd or similar). In OpenShift it is not possible to
+  use endpoints option, and configmaps is required. By default,
+  `kubernetes_use_configmaps: false`, meaning endpoints will be used.
+
 * **docker_image**
   Spilo Docker image for Postgres instances. For production, don't rely on the
   default image, as it might be not the most up-to-date one. Instead, build
@@ -613,11 +619,14 @@ operator being able to provide some reasonable defaults.
   the required minimum.
 
 * **connection_pooler_schema**
-  Schema to create for credentials lookup function. Default is `pooler`.
+  Database schema to create for credentials lookup function to be used by the
+  connection pooler. Is is created in every database of the Postgres cluster.
+  You can also choose an existing schema. Default schema is `pooler`.
 
 * **connection_pooler_user**
   User to create for connection pooler to be able to connect to a database.
-  Default is `pooler`.
+  You can also choose an existing role, but make sure it has the `LOGIN`
+  privilege. Default role is `pooler`.
 
 * **connection_pooler_image**
   Docker image to use for connection pooler deployment.

docs/user.md

@@ -527,7 +527,7 @@ spec:
 This will tell the operator to create a connection pooler with default
 configuration, through which one can access the master via a separate service
 `{cluster-name}-pooler`. In most of the cases the
-[default configuration](reference/operator_parameters.md#connection-pool-configuration)
+[default configuration](reference/operator_parameters.md#connection-pooler-configuration)
 should be good enough. To configure a new connection pooler individually for
 each Postgres cluster, specify:
 
@@ -540,7 +540,8 @@ spec:
     # in which mode to run, session or transaction
     mode: "transaction"
 
-    # schema, which operator will create to install credentials lookup function
+    # schema, which operator will create in each database
+    # to install credentials lookup function for connection pooler
     schema: "pooler"
 
     # user, which operator will create for connection pooler
@@ -560,11 +561,11 @@ The `enableConnectionPooler` flag is not required when the `connectionPooler`
 section is present in the manifest. But, it can be used to disable/remove the
 pooler while keeping its configuration.
 
-By default, `pgbouncer` is used as connection pooler. To find out about pooler
-modes read the `pgbouncer` [docs](https://www.pgbouncer.org/config.html#pooler_mode)
+By default, [`PgBouncer`](https://www.pgbouncer.org/) is used as connection pooler.
+To find out about pool modes read the `PgBouncer` [docs](https://www.pgbouncer.org/config.html#pooler_mode)
 (but it should be the general approach between different implementation).
 
-Note, that using `pgbouncer` a meaningful resource CPU limit should be 1 core
+Note, that using `PgBouncer` a meaningful resource CPU limit should be 1 core
 or less (there is a way to utilize more than one, but in K8s it's easier just to
 spin up more instances).