Patroni 4.1.5 Documentation
Running Patroni on memory-restricted systems with Python 3.11+
Unexpected behavior can occur with Python 3.11 or newer on systems with strict memory limits. For example, this includes vm.overcommit_memory=2, which is recommended for PostgreSQL. You may observe these symptoms:
- Patroni appears healthy
- PostgreSQL continues to run
- Patroni REST API becomes unresponsive
- The operating system reports that Patroni is listening on the REST API port
- Patroni logs look normal; however, following messages may appear once:
Exception ignored in thread started by: <object repr() failed>,MemoryError - Kernel logs may contain messages such as
not enough memory for the allocation
A bug in Python 3.11+ causes this behavior. Under strict memory conditions, a new thread may hang indefinitely if free memory is insufficient.
Recommended solution
Recent Patroni releases (4.1.1+, 4.0.8+) start all required threads early, before the system has memory pressure. This reduces the impact of the issue.
Additional recommendations (Linux, glibc)
When you use vm.overcommit_memory=2 (recommended for PostgreSQL), we also recommend these environment variables before you start Patroni:
MALLOC_ARENA_MAX=1- reduces the amount of virtual memory allocated by glibc for multi-threaded applicationsPG_MALLOC_ARENA_MAX=- resets the value ofMALLOC_ARENA_MAXfor PostgreSQL processes started by Patroni.
In addition, you may tune the following Patroni configuration parameters:
thread_stack_size- Stack size for threads that Patroni starts. A lower value reduces Patroni memory usage. The default is512kB. Increasethread_stack_sizeif Patroni has stack-related crashes. Otherwise, the default is sufficient.thread_pool_size- Thread pool size for asynchronous tasks and REST API communication with other members during leader races or failsafe checks. The default is5, which is sufficient for three-node clusters.restapi.thread_pool_size- Thread pool size for REST API requests. The default is5, which allows up to five parallel requests. Requests with SQL queries effectively run in sequence because they use one database connection. A higher value typically gives no benefit.
Patroni is a Python template for high availability (HA) PostgreSQL solutions. It supports distributed configuration stores such as ZooKeeper, etcd, Consul, and Kubernetes. Database engineers, DBAs, DevOps engineers, and SREs can use it to deploy HA PostgreSQL quickly in datacenters or other environments.
Patroni is a template. Its replication system needs configuration for your requirements and has limitations that you must consider. PostgreSQL supports many high-availability approaches. See the PostgreSQL Documentation for a list.
Currently supported PostgreSQL versions: 9.3 to 18.
Note to Citus users: Patroni 3.0 and later integrate with the Citus database extension to Postgres. See the Citus support page for Patroni high availability with a Citus distributed cluster.
Note to Kubernetes users: Patroni can run natively on Kubernetes. See the Kubernetes chapter.

Patroni introduction, quick start, and core high-availability concepts.
Installation and upgrade instructions for Patroni across supported platforms.
Patroni configuration model, precedence rules, and validation tooling.
Reference for Patroni REST API endpoints and operational behaviors.
Command reference for patronictl configuration, syntax, and subcommands.
Replica imaging, bootstrap, and custom replica creation workflows.
Asynchronous and synchronous replication modes managed by Patroni.
Standby cluster setup, behavior, and replication from remote primary.
Watchdog integration and fencing considerations for Patroni clusters.
Pause and resume mode behavior for Patroni cluster management.
DCS failsafe mode behavior, requirements, and operational caveats.
Using Patroni with Kubernetes objects, labels, and service discovery.
Patroni integration details for Citus coordinator and worker groups.
Procedure to convert existing PostgreSQL data into a Patroni cluster.
Integrating Patroni with external backup and orchestration tools.
Security considerations for DCS, REST API, and credential handling.
Multi-datacenter high-availability patterns with Patroni replication.
Frequently asked questions about Patroni operation and troubleshooting.
Chronological Patroni release notes and change history.
Contribution workflow, support channels, and development guidelines.
Was this page helpful?
Thanks—your feedback helps us improve this page.
What got in the way? (optional)