fix: Disable postgresql_server_tuning for buildah connections

Cause: Detecting available RAM and basing the shared memory settings of
the server on that is futile and wrong during a container image build.
The available RAM during that build is independent of the actual
runtime, be that a bootc deployment or a system container.

Consequence: postgresql.service failed to start when the available RAM
during container build was higher than at deployment time. In the
opposite case, the shared memory tuning was too small and thus also
wrong.

Fix: Disable `postgresql_server_tuning` by default for container builds,
i.e. when being connected to a buildah instance.

Author: martinpitt

README.md

@@ -143,6 +143,11 @@ based on system resources. To disable the tuning, set the
 postgresql_server_tuning: false
 ```
 
+However, when running against a
+[buildah connection](https://docs.ansible.com/ansible/latest/collections/containers/podman/buildah_connection.html),
+i.e. a container build, this defaults to `false`. The available RAM during a
+container build is independent of the actual deployment.
+
 See the [`examples/`](examples) for details.
 
 ## Idempotence

defaults/main.yml

@@ -10,7 +10,10 @@ postgresql_version: "{{ '16' if ansible_facts['os_family'] == 'RedHat'
   else '13' }}"
 postgresql_password: null
 postgresql_cert_name: null
-postgresql_server_tuning: true
+# the container build environment's RAM is independent from the deployment
+# (regardless if it's a bootc or system container one), so disable tuning there
+# by default
+postgresql_server_tuning: "{{ false if (ansible_connection | d('')) == 'buildah' else true }}"
 postgresql_ssl_enable: false
 
 # If you want to generate the certificas in the postgresql role