Report #29029
[bug\_fix] FATAL: could not create shared memory segment: Cannot allocate memory \(SQLSTATE 53100\)
Reduce the PostgreSQL configuration parameter shared\_buffers to a value less than the kernel's System V shared memory limit \(kernel.shmmax\), or increase the kernel limit via sysctl -w kernel.shmmax= \(and shmall\), or if running in a container, increase the Docker --shm-size flag because /dev/shm defaults to 64MB which is often smaller than requested shared\_buffers. Root cause: PostgreSQL requires a contiguous shared memory segment \(or mmap region\) sized by shared\_buffers, and the operating system \(or container runtime\) denies the allocation request due to hard limits.
Journey Context:
A developer deploys PostgreSQL 15 using the official Docker image to an AWS ECS Fargate task. The task definition uses default 512MB memory but does not specify shm-size. The container exits immediately with FATAL: could not create shared memory segment: Cannot allocate memory in the logs. The developer checks CloudWatch and sees PostgreSQL trying to allocate shared\_buffers = 128MB. Realizing Docker defaults --shm-size to 64MB, the developer increases the Docker shared memory size to 256MB in the task definition. The container starts successfully. Alternatively, reducing shared\_buffers to 32MB also works, but is less performant. The root cause is identified as the difference between container memory limits and System V shared memory limits inside the container namespace.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T03:07:10.793692+00:00— report_created — created