Error while dialing: dial unix /plugins/barman-cloud.cloudnative-pg.io: connect: connection refused

[smiyc]

Plugin Version: 0.11.0

Due to memory Problems like reported in #385

I set limits to the ObjectStore like this

...
# https://github.com/cloudnative-pg/plugin-barman-cloud/issues/385
    resources:
      limits:
        # cpu: 500m
        memory: 500Mi
      # requests:
        # cpu: 200m
        # memory: 256Mi   
...

after that, the backups where running fine for some time and at some point WAL archiving stopped working.
The time was ~11:40.
As seen in the first screenshot, the plugin-barman-cloud contiantainer was using ~27MB of RAM at this time, so far away from the limit.

This is the error reported by the postgresql container

postgres {"level":"error","ts":"2026-03-13T07:31:39.700915233+01:00","logger":"wal-archive","msg":"Error while loading required plugins","logging_pod":"confluence-wit-dev-1","error":"while getting plugin connection: while querying plugin identity: rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial unix /plugins/barman-cloud.cloudnative-pg.io: connect: connection refused\"","stacktrace":"github.com/cloudnative-pg/machinery/pkg/log.(*logger).Error\n\tpkg/mod/github.com/cloudnative-pg/machinery@v0.3.3/pkg/log/log.go:125\ngithub.com/cloudnative-pg/cloudnative-pg/pkg/management/postgres/archiver.archiveWALViaPlugins\n\tpkg/management/postgres/archiver/archiver.go:292\ngithub.com/cloudnative-pg/cloudnative-pg/pkg/management/postgres/archiver.internalRun\n\tpkg/management/postgres/archiver/archiver.go:168\ngithub.com/cloudnative-pg/cloudnative-pg/pkg/management/postgres/archiver.Run\n\tpkg/management/postgres/archiver/archiver.go:153\ngithub.com/cloudnative-pg/cloudnative-pg/internal/cmd/manager/walarchive.NewCmd.func1\n\tinternal/cmd/manager/walarchive/cmd.go:65\ngithub.com/spf13/cobra.(*Command).execute\n\tpkg/mod/github.com/spf13/cobra@v1.10.2/command.go:1015\ngithub.com/spf13/cobra.(*Command).ExecuteC\n\tpkg/mod/github.com/spf13/cobra@v1.10.2/command.go:1148\ngithub.com/spf13/cobra.(*Command).Execute\n\tpkg/mod/github.com/spf13/cobra@v1.10.2/command.go:1071\nmain.main\n\tcmd/manager/main.go:71\nruntime.main\n\t/opt/hostedtoolcache/go/1.25.7/x64/src/runtime/proc.go:285"}

The WAL backup started working after I removed the limits.

So the question is, is the error related to the Memory Limit?

I checkt the memory usage from the other barman containers and there is still an memory issue in 0.11.0.
Some clusters are using up to 3-4GB and one cluster is using up to 10GB for the plugin!

[dosubot]

The "connection refused" error is indeed related to memory limits, but not in the way you might expect. Even though your actual memory usage shows ~27MB, Kubernetes counts OS-level caching (used during WAL archiving operations) against the container's memory limit. The container_memory_working_set_bytes metric includes kernel slab_reclaimable memory, so the actual reported usage to Kubernetes can be much higher than the Go process itself uses.

When the limit is exceeded, the plugin container gets OOMKilled, causing the unix socket at /plugins/barman-cloud.cloudnative-pg.io to become unavailable, which results in the "connection refused" error.

Regarding the memory leak: The original memory leak (#385) was fixed in v0.11.0 via PR #746. The root cause was Python bytecode recompilation on every invocation due to the read-only filesystem. However, the 3-10GB memory usage you're seeing in some clusters is likely OS-level page caching during backup operations, not an actual memory leak. You can verify this by monitoring container_memory_rss instead of container_memory_working_set_bytes - the RSS should show much lower, stable values.

Recommended fix: Increase your memory limit to at least 500Mi and set both requests and limits to the same value for Kubernetes "Guaranteed" QoS class:

resources:
  requests:
    memory: "500Mi"
    cpu: "250m"
  limits:
    memory: "500Mi"
    cpu: "250m"

For larger databases or high WAL generation rates, you may need more. Users with 1-32GB databases have reported 350-500Mi as the minimum for stable operation.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[smiyc]

@mnencia @sxd
do you agree that the solution for an OOM caused by a resource limit, is setting the same limit again, but this time as "Guaranteed QoS"?