public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andres Freund <[email protected]>
To: Tom Lane <[email protected]>
Cc: Thomas Munro <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: A stack allocation API
Date: Fri, 27 Feb 2026 13:02:30 -0500
Message-ID: <rc5bkn7ikwo6cir5w4jilxtqeiczdup7ytooav7lufa77brz5p@54gexczvq25p> (raw)
In-Reply-To: <[email protected]>
References: <CA+hUKG+ixUUYOGRcuZpkk5pmJZaUQv6VCPAjdTZXFP5vA8jxcA@mail.gmail.com>
	<[email protected]>

Hi,

On 2026-02-27 10:35:39 -0500, Tom Lane wrote:
> Thomas Munro <[email protected]> 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

view thread (6+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: A stack allocation API
  In-Reply-To: <rc5bkn7ikwo6cir5w4jilxtqeiczdup7ytooav7lufa77brz5p@54gexczvq25p>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox