MIME-Version: 1.0
References: <223EA201-A0E8-4A13-B220-EB903E8DF817@eggerapps.at>
 <871806.1778168884@sss.pgh.pa.us> <873909.1778170924@sss.pgh.pa.us>
 <CAP53PkzLmeNUiNtcOyw62KkD7OzthdCbkwGTyAk+Lu3LKsmOcg@mail.gmail.com>
In-Reply-To: 
 <CAP53PkzLmeNUiNtcOyw62KkD7OzthdCbkwGTyAk+Lu3LKsmOcg@mail.gmail.com>
From: John Naylor <johncnaylorls@gmail.com>
Date: Fri, 8 May 2026 10:48:55 +0700
Message-ID: 
 <CANWCAZa5TEmjLy0xtBjP9NyuVCJpCOpVkBSzw-fqmH8D9tFzDg@mail.gmail.com>
Subject: Re: Broken build on macOS (Universal / Intel): cpuid instruction not
 available
To: Lukas Fittl <lukas@fittl.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jakob Egger <jakob@eggerapps.at>,
	pgsql-hackers <pgsql-hackers@postgresql.org>,
 Tobias Bussmann <t.bussmann@gmx.net>,
	Andres Freund <andres@anarazel.de>
Content-Type: multipart/mixed; boundary="0000000000005b1d9206514647af"
Archived-At: 
 <https://www.postgresql.org/message-id/CANWCAZa5TEmjLy0xtBjP9NyuVCJpCOpVkBSzw-fqmH8D9tFzDg%40mail.gmail.com>
Precedence: bulk

--0000000000005b1d9206514647af
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, May 8, 2026 at 12:34=E2=80=AFAM Lukas Fittl <lukas@fittl.com> wrote=
:
>
> On Thu, May 7, 2026 at 9:22=E2=80=AFAM Tom Lane <tgl@sss.pgh.pa.us> wrote=
:
> >
> > I wrote:
> > > ... The code in HEAD doesn't have
> > > that guard, and is essentially assuming that every x86 platform
> > > wil provide HAVE__GET_CPUID or HAVE__CPUID.
> >
> > Independently of whether macOS multi-arch is something we consider
> > supportable, I think the aforesaid assumption is a bad idea.
> > Can't we make pg_cpuid() return zeroes if it doesn't know how to
> > get the info, analogously to what pg_cpuid_subleaf() does?

Yeah, that seems like a good assumption to remove.

Jakob and Tobias, how far do you get with the attached, at least for
the target x86 case? And it might help if you sent the configure
output in a file so we can see what we're dealing with. Note also that
we have two build systems, since we'll likely transition away from
autotools:

https://wiki.postgresql.org/wiki/Meson

> Having worked in that area in this cycle, I think returning zeroes (or
> adding a return value that confirms we got data)

Speaking of return values, the TSC feature as committed doesn't
actually use the return value of pg_cpuid_subleaf(), but it seems like
something we could use someday. I don't see such a use for pg_cpuid()
beyond having zero values in the 4 variables.

> could work for the
> TSC related functionality, since we just fall back to the system clock
> and disallow TSC use if we can't get CPUID data. I'll let John confirm
> if there are any other optimizations that require CPUID data.

Yes there are, but everything should still fallback gracefully without it.

--
John Naylor
Amazon Web Services

--0000000000005b1d9206514647af
Content-Type: text/x-patch; charset="US-ASCII";
 name="dont-assume-cpuid-available.patch"
Content-Disposition: attachment;
	filename="dont-assume-cpuid-available.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mowde7xm0>
X-Attachment-Id: f_mowde7xm0

ZGlmZiAtLWdpdCBhL3NyYy9wb3J0L3BnX2NwdV94ODYuYyBiL3NyYy9wb3J0L3BnX2NwdV94ODYu
YwppbmRleCBmMjIxNjdkYTlhZi4uZjYxZjA5NDA0MzEgMTAwNjQ0Ci0tLSBhL3NyYy9wb3J0L3Bn
X2NwdV94ODYuYworKysgYi9zcmMvcG9ydC9wZ19jcHVfeDg2LmMKQEAgLTYzLDEyICs2MywxMSBA
QCBtYXNrX2F2YWlsYWJsZSh1aW50MzIgdmFsdWUsIHVpbnQzMiBtYXNrKQogc3RhdGljIGlubGlu
ZSB2b2lkCiBwZ19jcHVpZChpbnQgbGVhZiwgdW5zaWduZWQgaW50ICpyZWcpCiB7CisJbWVtc2V0
KHJlZywgMCwgNCAqIHNpemVvZih1bnNpZ25lZCBpbnQpKTsKICNpZiBkZWZpbmVkKEhBVkVfX0dF
VF9DUFVJRCkKIAlfX2dldF9jcHVpZChsZWFmLCAmcmVnW0VBWF0sICZyZWdbRUJYXSwgJnJlZ1tF
Q1hdLCAmcmVnW0VEWF0pOwogI2VsaWYgZGVmaW5lZChIQVZFX19DUFVJRCkKIAlfX2NwdWlkKChp
bnQgKikgcmVnLCBsZWFmKTsKLSNlbHNlCi0jZXJyb3IgY3B1aWQgaW5zdHJ1Y3Rpb24gbm90IGF2
YWlsYWJsZQogI2VuZGlmCiB9CiAK
--0000000000005b1d9206514647af--