Re: Broken build on macOS (Universal / Intel): cpuid instruction not available - Mailing list pgsql-hackers

From Lukas Fittl
Subject Re: Broken build on macOS (Universal / Intel): cpuid instruction not available
Date
Msg-id CAP53PkzLmeNUiNtcOyw62KkD7OzthdCbkwGTyAk+Lu3LKsmOcg@mail.gmail.com
Whole thread
In response to Re: Broken build on macOS (Universal / Intel): cpuid instruction not available  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Broken build on macOS (Universal / Intel): cpuid instruction not available
List pgsql-hackers
On Thu, May 7, 2026 at 9:22 AM 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?

Having worked in that area in this cycle, I think returning zeroes (or
adding a return value that confirms we got data) 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.

CCing Andres as well, since he reviewed some of those patches for pg_cpu_x86.c.

Thanks,
Lukas

--
Lukas Fittl



pgsql-hackers by date:

Previous
From: lloyd thealbins.com
Date:
Subject: apt files missing for PG18
Next
From: Dmitry Dolgov
Date:
Subject: Re: Randomize B-Tree page split location to avoid oscillating patterns