Changing shared_buffers on the fly
summary
Proposes changing shared_buffers at runtime by splitting the big shared segment into per-structure mappings, reserving address space and using anonymous backing file growth (ftruncate) with optional fallocate to force allocation so remap is unnecessary. Prototype coordinates resize in a single phase, handles dirty buffer eviction and pinned-buffer choices, leaves buffer-lookup resizing as an open problem, and accepts Linux-first deployment; failures can abort or roll back or—worst case—require restart.
AI-written summary · about
chapters (9)
- 0:00Introduction and motivation
- 5:22Current shared buffers limitations
- 13:42Shared memory layout details
- 23:12Resizing shared buffers challenges
- 30:02Synchronizing resizing across processes
- 37:54User experience and triggering resizing
- 45:14Cross-platform considerations
- 51:03Huge pages and memory constraints
- 52:05Q&A and closing
related talks
45mEnhancing PostgreSQL Plasticity: New Frontiers in Memory Management
21mLessons Learned Building a Production Memory-Overcommit Solution
37mLarge Block I/O for Linux
27mEfficient shared memory data structures
01h 07mEmerging Embdedded Memories and Storage
01h 13mC++ Memory Model Meets High-Update-Rate Data Structures
50mInside PostgreSQL Shared Memory
29mVirtio-(balloon|pmem|mem): Managing Guest Memory