Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vTiei-008wnU-0E for pgsql-hackers@arkaria.postgresql.org; Thu, 11 Dec 2025 15:32:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vTief-004AFt-2z for pgsql-hackers@arkaria.postgresql.org; Thu, 11 Dec 2025 15:32:34 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vTief-004AFl-21 for pgsql-hackers@lists.postgresql.org; Thu, 11 Dec 2025 15:32:34 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vTiee-000ACa-1j for pgsql-hackers@postgresql.org; Thu, 11 Dec 2025 15:32:33 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 5BBFWQtB830616; Thu, 11 Dec 2025 10:32:26 -0500 From: Tom Lane To: David Geier cc: Michael Paquier , Thomas Munro , Chao Li , pgsql-hackers Subject: Re: Consistently use palloc_object() and palloc_array() In-reply-to: References: <524587.1764365323@sss.pgh.pa.us> <1e7f0c17-a965-4d5b-ad88-b435a4d97490@gmail.com> <143d3184-b575-49bd-8bc1-f37f45f010cc@gmail.com> <534126.1764722446@sss.pgh.pa.us> <4ab4a12b-49e9-4ebf-9055-225c8055fed0@gmail.com> <1433178.1764946037@sss.pgh.pa.us> Comments: In-reply-to David Geier message dated "Thu, 11 Dec 2025 08:54:31 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <830614.1765467146.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Dec 2025 10:32:26 -0500 Message-ID: <830615.1765467146@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk David Geier writes: > Do we know what code each build animal actually has enabled? Of course. The configuration is reported in the logs of every buildfarm run. For instance, in the most recent run at this moment, https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Dcaiman&dt=3D2025= -12-11%2015%3A00%3A05 we can see $ ./configure --enable-cassert --enable-debug --enable-nls --with-perl \ --with-python --with-tcl --with-gssapi --with-openssl --with-ldap = \ --with-libxml --with-libxslt --with-pam --with-selinux \ --with-systemd --with-liburing --with-libcurl --with-libnuma \ --with-lz4 --with-zstd --prefix=3D/repos/client-code-REL_20/HEAD/i= nst \ --with-pgport=3D5678 --cache-file=3D/repos/client-code-REL_20/acca= che-caiman/config-HEAD.cache and you can drill down to the "configure" step if you want more detail. > 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? It's the owner's choice. The buildfarm client's sample config file has a list of suggested options, and I wouldn't be too surprised if a lot of people just left that list alone. I think the ones paying closer attention probably try to enable as much as they can. regards, tom lane