Allow Mounting Custom Volumes into the Main patroni Container

Problem to solve

The StackGres operator allows adding custom sidecars via the spec.pods.customContainers field, which is excellent. However, there is currently no mechanism to mount a shared volume (for example an emptyDir volume) into both a custom sidecar and the main patroni (Postgres) container.

This limitation prevents using high-performance, low-latency Inter-Process Communication (IPC) mechanisms like Unix domain sockets, which require a shared filesystem path.

Further details

For any helper sidecar that needs to be called frequently, for example, from a PL/pgSQL function, the overhead of even a localhost TCP/IP network call can become a performance bottleneck in high-throughput scenarios.

Enabling this feature would unlock advanced use cases and improve performance for any service requiring high-frequency communication with the database from a sidecar.

The primary benefit is a significant reduction in communication latency between PostgreSQL and its sidecars, leading to higher overall performance for certain architectural patterns.

Proposal

Allow using the spec.pods.customVolumeMounts field in the main patroni container.

A potential implementation could look like this in the SGCluster CRD:

# ...
spec:
  pods:
    customVolumes:
      - name: ipc-sockets
        emptyDir: {}
    
    # Allow the existing customVolumeMounts field to target 'patroni'
    customVolumeMounts:
      - container: patroni # Allow targeting the main postgres container
        volume: ipc-sockets
        mountPath: /ipc
      - container: my-sidecar # Continue to support custom sidecars
        volume: ipc-sockets
        mountPath: /ipc

This would provide a flexible and secure way to establish a shared filesystem between the core database process and its helper sidecars.

Alternatively, introduce new spec.pods.sharedVolumeMounts field.

Testing

Risks:

  • Mounting volumes into the core patroni container could potentially interfere with the operator's expected filesystem layout if not handled carefully.
  • The lifecycle of the shared volume must be managed correctly by the operator to avoid conflicts during Pod restarts or upgrades.

Test Plan:

  • Deploy a cluster with a shared emptyDir volume mounted to both patroni and a simple busybox sidecar.
  • Verify that both containers can read and write to a file in the shared volume.
  • Verify that a Unix socket can be created by the sidecar and accessed by a process running inside the patroni container.

Acceptance Criteria

  • A user can define a volume (e.g., emptyDir) in spec.pods.customVolumes.
  • A user can specify a mount for that volume into the patroni container by reusing the existing customVolumeMounts field.
  • A user can mount the same volume into a sidecar defined in the SGCluster's spec.pods.customContainers section.
  • When the cluster is deployed, the Pod starts successfully with the shared volume mounted in both containers.
  • A process in the sidecar container can communicate with a process in the patroni container via a Unix domain socket located on the shared volume.

Links / references

N/A