On Fri, Oct 9, 2026 at 9:37 PM Andres Freund <[email protected]> wrote:
> > > > 5) I think we should add a mode to all our allocators that just turns > > > every > > > allocation into a large allocation (perhaps with something slightly > > > different for slab). In that mode asan, valgrind, et al would be more > > > precise. Of course that'll have rather deleterious performance > > > effects, > > > but I think it'd still be quite useful for debugging. > > > > I think this has an advantage of its own, we will benefit from memory > > sanity check improvements in system calls without necessarily > > implementing them in PostgreSQL and also use-after-free failure not > > necessarily covered by other proposals. > > I'm not really following, which memory sanity checking in system calls are you > thinking of? > I used “system calls” incorrectly; I meant the underlying allocator and the memory-debugging infrastructure around its allocation interfaces. The point I was trying to make was slightly broader than the immediate increase in ASAN/Valgrind precision. PostgreSQL’s memory-context infrastructure and MEMORY_CONTEXT_CHECKING date from 2000. Valgrind appeared later, ASAN much later, and allocator/tooling features such as redzones, quarantine and other hardening have continued to improve since then. If, in this mode, each palloc() is represented by a separate underlying allocation, its boundary is visible directly to that allocator and to tools interposing on malloc()/free(). PostgreSQL could therefore benefit "immediately" from future improvements in those allocators and tools without necessarily having to reproduce each new check in every memory-context implementation. If we had this mode today, we would automatically benefit from use-after-free checking. Of course, this only applies to checks that operate at the underlying allocation boundary, and your proposed ASAN annotations would cover many of the same cases. So this is probably not an advantage separate from the “ASAN, Valgrind, et al would be more precise” point you already made. It is more the future-proofing aspect of exposing each allocation to that infrastructure. Is that already what you had in mind? Thanks for sharing patches, will take a look at them soon. -- Best Wishes, Ashutosh Bapat
