Feedback-ID: id4a34324:Fastmail
Date: Fri, 27 Feb 2026 13:02:30 -0500
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Thomas Munro <thomas.munro@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: A stack allocation API
Message-ID: <rc5bkn7ikwo6cir5w4jilxtqeiczdup7ytooav7lufa77brz5p@54gexczvq25p>
References: <CA+hUKG+ixUUYOGRcuZpkk5pmJZaUQv6VCPAjdTZXFP5vA8jxcA@mail.gmail.com>
 <854785.1772206539@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <854785.1772206539@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/rc5bkn7ikwo6cir5w4jilxtqeiczdup7ytooav7lufa77brz5p%4054gexczvq25p>
Precedence: bulk

Hi,

On 2026-02-27 10:35:39 -0500, Tom Lane wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > I also wondered if we might have a reasonable case for using alloca(),
> > where available.  It's pretty much the thing we are emulating, but
> > keeps the stack nice and compact without big holes to step over for
> > the following call to strcoll_l() or whatever it might be.
>
> +1 for investigating alloca().  The one disadvantage I can see
> to making this coding pattern more common is that it'll result in
> increased stack usage, which is not great now and will become
> considerably less great in our hypothetical multithreaded future.

Yea, that's what I immediately was thinking about too. IIRC, on linux, the
stack for the "main" thread is allocated on-demand, but the stack for threads
is mapped entirely upon creation (I think because it'd be hard to ensure
there's space for the stack otherwise). So there's more benefit in keeping the
stack small-ish with threads than there is in a process based model.


That said, I've thought about accellerating a few things with an
'on-stack-if-small-palloc-otherwise' approach as well.  Particularly things
like small StringInfos could really benefit from it - but it'd be a nontrivial
conversion, due code calling pfree on the memory.  I guess we could introduce
a memory context that'd do nothing for pfree(), which could be used when using
the stack version, but IDK, that seems mighty ugly.


However, I'm pretty unconvinced of this argument

> in the past we've forgotten to pfree() large allocations and had to fix leaks

because we'll continue to rely on calling something to free anyway (due to
large objects) and using a different path for smaller objects just will make
it harder to find those.


I wish msvc implemented something akin to gcc/clang's
attribute(cleanup(cleanup_function)), but it doesn't look like it
does. Obviously it would if we were to compile with C++, but I don't think
anybody has appetite for the work it'd need to get there.

Greetings,

Andres Freund