June 23rd, 2024

Post-mortem: Postgres out of shared memory error

An investigation into PostgreSQL's memory error highlighted insights on transaction isolation and lock management. Increasing max_locks_per_transaction can resolve the "out of shared memory" issue, crucial for maintaining data consistency and preventing memory errors.

Read original articleLink Icon
Post-mortem: Postgres out of shared memory error

A recent investigation into PostgreSQL's "out of shared memory" error revealed insights into transaction isolation and lock management. The error occurs when Postgres exhausts its lock memory capacity, determined by max_locks_per_transaction * (max_connections + max_prepared_transactions). Increasing max_locks_per_transaction can resolve this issue. Understanding transaction isolation levels, like Repeatable Read, is crucial as Postgres enforces isolation requirements to maintain data consistency. SIReadLocks are used to track accessed rows, impacting memory usage. Long-running non-READ ONLY transactions or orphaned transactions can lead to lock accumulation and memory saturation. Monitoring and addressing these issues, such as setting idle_in_transaction_session_timeout, can prevent memory errors and ensure database performance.

Related

Trealla Prolog: Compact and efficient Prolog interpreter

Trealla Prolog: Compact and efficient Prolog interpreter

Trealla Prolog is a compact interpreter written in C, compliant with ISO Prolog. It supports unbounded integers, UTF-8 atoms, efficient strings, and runs on Linux, Android, and WebAssembly. It offers C integration, SQLite access, concurrency features, and experimental functionalities. The project is open source under the MIT license.

Schema changes and the Postgres lock queue

Schema changes and the Postgres lock queue

Schema changes in Postgres can cause downtime due to locking issues. Tools like pgroll help manage migrations by handling lock acquisition failures, preventing application unavailability. Setting lock_timeout on DDL statements is crucial for smooth schema changes.

Lessons Learned from Scaling to Multi-Terabyte Datasets

Lessons Learned from Scaling to Multi-Terabyte Datasets

Insights on scaling to multi-terabyte datasets, emphasizing algorithm evaluation before scaling. Tools like Joblib and GNU Parallel for single machine scaling, transitioning to multiple machines, and comparing performance/cost implications. Recommendations for parallel workloads and analytical tasks using AWS Batch, Dask, and Spark. Considerations for tool selection based on team size and workload.

Postgres Schema Changes and Locking

Postgres Schema Changes and Locking

Schema changes in Postgres can cause downtime by locking out reads and writes. Migration tools help mitigate issues. Breakages during migrations can affect client apps or lock database objects, leading to unavailability. Long queries with DDL statements can block operations. Setting lock_timeout on DDL statements can prevent queuing. Tools like pgroll offer backoff and retry strategies for lock acquisition failures. Understanding schema changes and DDL impact helps ensure smoother migrations and less downtime.

Memory Model: The Hard Bits

Memory Model: The Hard Bits

This chapter explores OCaml's memory model, emphasizing relaxed memory aspects, compiler optimizations, weakly consistent memory, and DRF-SC guarantee. It clarifies data races, memory classifications, and simplifies reasoning for programmers. Examples highlight data race scenarios and atomicity.

Link Icon 0 comments