Horton

Re: Consistently use palloc_object() and palloc_array()

David Geier <geidav.pg@gmail.com>

View thread
From: David Geier <geidav.pg@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>, Thomas Munro <thomas.munro@gmail.com>, Chao Li <li.evan.chao@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-12-11T07:54:31Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. btree_gist: Fix memory allocation formula

  2. Use palloc_object() and palloc_array(), the last change

  3. pg_buffercache: Fix memory allocation formula

  4. Fix allocation formula in llvmjit_expr.c

  5. Use palloc_object() and palloc_array() in backend code

  6. Use palloc_object() and palloc_array() in more areas of the tree

  7. Use more palloc_object() and palloc_array() in contrib/

On 05.12.2025 15:47, Tom Lane wrote:
> David Geier <geidav.pg@gmail.com> writes:
>> My bad. I hadn't realized that - obviously - not necessarily all code is
>> actually compiled by default.
> 
>> Will the build system enable any target for which all dependencies (e.g.
>> libraries) are met, or are there targets that need to be enabled
>> explicitly? Is there a way to enable all of them so I can easily make
>> sure, I actually compile all code?
> 
> There's a good deal of platform-specific code in PG, particularly for
> Windows, and obviously none of that will be built unless you're on the
> right platform.  (You can reach some of the Windows-specific code on
> other systems with -DEXEC_BACKEND, but that goes only so far.)
> 
> As for optional-feature stuff, I think the meson build system will by
> default build every option it can find the supporting libraries for.
> But the other side of that coin is that if you didn't install the
> right packages it will silently not build it.
> 
> I think the most reliable way is to look at "./configure --help"
> and select all the options you think should work on your platform.
> Then, if you forgot to install libfoo-devel or whatever, you'll
> get configure failures.

Thanks for the pointers.

Do we know what code each build animal actually has enabled? The
platform specific code is clear but anything that depends on specific
libraries being installed is not.

Do build animal owners try to enable as much code as possible, or is
this completely up to what the owner happened to do when setting up the
build animal?

I'm wondering how much more code coverage we could get on each animal if
maximized the amount of code that is enabled.

--
David Geier