From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: A stack allocation API
In-reply-to: <CA+hUKG+ixUUYOGRcuZpkk5pmJZaUQv6VCPAjdTZXFP5vA8jxcA@mail.gmail.com>
References: <CA+hUKG+ixUUYOGRcuZpkk5pmJZaUQv6VCPAjdTZXFP5vA8jxcA@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@gmail.com>
	message dated "Sat, 28 Feb 2026 00:59:42 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <854784.1772206539.1@sss.pgh.pa.us>
Date: Fri, 27 Feb 2026 10:35:39 -0500
Message-ID: <854785.1772206539@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/854785.1772206539%40sss.pgh.pa.us>
Precedence: bulk

Thomas Munro <thomas.munro@gmail.com> writes:
> In the locale code we often use a 1KB array for copies of strings
> where we need a NUL-terminated or transcoded version to give a library
> function, with a fallback to palloc() + pfree() if we need more space
> than that, but:

Yeah, I think there are some other use-cases too.

> 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.
If we can fix it so the typical stack consumption is a good deal
less than 1KB, that worry would be alleviated.

			regards, tom lane