No video of the event yet, sorry!

Talk Proposal: Finding Hidden Memory Bugs in PostgreSQL with Custom Memory Allocators

Track: Database Engine Developers

Level: Intermediate to Advanced

Duration: 45 minutes (30 min presentation + 15 min Q&A)

Abstract

Memory safety bugs in PostgreSQL are notoriously difficult to detect. While tools like Valgrind and AddressSanitizer (ASan) help, PostgreSQL's AllocSet memory context—optimized for production performance with freelists and bulk allocations—can mask critical use-after-free vulnerabilities that slip through standard testing.

This talk presents a novel debugging approach: a custom malloc-based allocator that bypasses PostgreSQL's freelists to immediately release memory, maximizing ASan's effectiveness. Using this technique, we discovered three critical use-after-free bugs in PostgreSQL v16-v18 that all existing memory safety checks missed—bugs that were fixed and committed upstream.

The Three Bugs Discovered

1. Window Aggregate Use-After-Free (v16.3): Memory freed during run condition failure but pointer not nullified, causing crashes in window functions with TEXT columns. Discussion

2. Parallel Vacuum Dead Items Reset (v17.2): Fix use-after-free in parallel_vacuum_reset_dead_items. Discussion

3. Leader Process Stale Pointer (v17-v18): Fix reuse-after-free hazard in dead_items_reset. Discussion

What to learn

• How PostgreSQL's memory context architecture can hide bugs
• Why custom allocators + ASan catch bugs that Valgrind and standard tools miss
• Practical techniques for integrating custom allocators into PostgreSQL (v16+ challenges)
• Real-world debugging workflows for memory corruption issues
• How to contribute memory safety improvements to the PostgreSQL community

Key Takeaways

1. Performance optimizations can hide bugs: Freelists that improve production speed can mask memory corruption
2. Tool diversity matters: Different testing approaches catch different bug classes
3. Memory poisoning requires actual freeing: ASan can only detect use-after-free if memory is freed and poisoned, not cached
4. Same-address reallocation is insidious: When allocators return the same memory location, bugs become invisible even to ASan

This work demonstrates the critical value of "performance-degraded" testing modes and shows how community collaboration in bug discovery benefits all PostgreSQL users.

Target Audience: PostgreSQL core developers, extension developers, QA engineers, DBAs interested in PostgreSQL internals, systems programmers working on database reliability