Re: Make memory checking / sanitizing infrastructure better

On Fri, Oct 9, 2026 at 9:37 PM Andres Freund <andres(at)anarazel(dot)de> 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