This archive preserves educational material on data warehousing and ETL operations, originally compiled to support professionals working with analytical systems. The content focuses on system architecture, data flow analysis, and the practical challenges of managing operational data — including the configuration of shared infrastructure such as PostgreSQL memory segments within containerized environments.
Key point 1. The preserved excerpts reflect a teaching emphasis on converting raw data into actionable business insight, with attention to performance, reliability, and the integration of multiple reporting tools. While the original materials referenced specific industry applications, this site now serves solely as a neutral reference for those studying database administration, warehouse design, and related technical practices.
Key point 2. No current organization, certification, or service is implied. The material is offered for educational purposes only, and readers should verify any technical guidance against contemporary documentation and their own system requirements.
PostgreSQL Shared Memory Segments in Docker Compose: A Practical Guide. When running PostgreSQL inside Docker Compose, one of the most common runtime failures is the `could not resize shared memory segment` error, often accompanied by `No space left on device` even when your disk has plenty of free space. This happens because PostgreSQL uses POSIX shared memory (`/dev/shm`) for its shared buffers and parallel query execution, and Docker containers by default receive a tiny 64 MB `/dev/shm` mount. This guide explains how to diagnose, size, and configure shared memory for PostgreSQL in Docker Compose, with concrete examples and decision criteria.
Key point 5. The critical distinction: `shared_buffers` is *not* the problem in most Docker failures. The problem is DSM. When you run a query with `parallel_workers` set, PostgreSQL creates temporary shared memory segments in `/dev/shm`. If the container's `/dev/shm` is only 64 MB, even a modest parallel query can exhaust it.
The Default Docker Problem. Docker's default `/dev/shm` size is 64 MB. PostgreSQL's default `shared_buffers` is 128 MB, but that lives in the main anonymous shared memory, not `/dev/shm`. However, PostgreSQL also checks the available space in `/dev/shm` at startup and may refuse to start if it thinks there isn't enough for its expected DSM usage.
You will see errors like:. ```
FATAL: could not create shared memory segment: No space left on device.
DETAIL: Failed system call: shmget(key=1, size=...)
```.
or. ```
ERROR: could not resize shared memory segment "/PostgreSQL.XXX" to N bytes: No space left on device.
```.
There is no single correct value, but you can derive a safe starting point from your PostgreSQL configuration.
Decision Criteria
A practical formula for a typical web application:
```
shm_size = shared_buffers + (max_connections * 4 MB) + 256 MB.
```.
For example, with `shared_buffers = 1 GB` and `max_connections = 100`:
```
1 GB + (100 * 4 MB) + 256 MB = 1 GB + 400 MB + 256 MB = ~1.6 GB.
```.
Key point 13
Round up to the next power of 2 or a clean number: `2 GB` is a reasonable choice.
Inside a running container, run:
```bash
```.
This shows the current size and usage. To see actual DSM segments:
```bash
```.
Key point 16
If you see many `PostgreSQL.` files, your workload is actively using DSM.
Configuring Docker Compose
The `shm_size` directive is supported in Docker Compose for both services and top-level volumes. Here is a minimal working example:
This independent educational reference summarizes general technical concepts. Verify current standards, dimensions, and manufacturer specifications before making a procurement or engineering decision.