Re: Broken build on macOS (Universal / Intel): cpuid instruction not available

From: Lukas Fittl <lukas(at)fittl(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: John Naylor <johncnaylorls(at)gmail(dot)com>, Jakob Egger <jakob(at)eggerapps(dot)at>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tobias Bussmann <t(dot)bussmann(at)gmx(dot)net>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Broken build on macOS (Universal / Intel): cpuid instruction not available
Date: 2026-05-07 17:33:33
Message-ID: CAP53PkzLmeNUiNtcOyw62KkD7OzthdCbkwGTyAk+Lu3LKsmOcg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 7, 2026 at 9:22 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Dolgov 2026-05-07 18:10:30 Re: Randomize B-Tree page split location to avoid oscillating patterns
Previous Message lloyd thealbins.com 2026-05-07 17:33:26 apt files missing for PG18