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.94.2) (envelope-from ) id 1t6kxo-00FJa1-M8 for pgsql-bugs@arkaria.postgresql.org; Fri, 01 Nov 2024 06:16:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1t6kxm-009vcH-V9 for pgsql-bugs@arkaria.postgresql.org; Fri, 01 Nov 2024 06:16:51 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t6kxm-009vbm-Ln for pgsql-bugs@lists.postgresql.org; Fri, 01 Nov 2024 06:16:51 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t6kxk-0048JV-6V for pgsql-bugs@lists.postgresql.org; Fri, 01 Nov 2024 06:16:50 +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 4A16GWiN1637255; Fri, 1 Nov 2024 02:16:32 -0400 From: Tom Lane To: Thomas Munro cc: Heikki Linnakangas , =?UTF-8?Q?Bastien_Roucari=C3=A8s?= , pgsql-bugs@lists.postgresql.org Subject: Re: Detection of hadware feature => please do not use signal In-reply-to: <1624905.1730436275@sss.pgh.pa.us> References: <4496616.iHFcN1HehY@portable-bastien> <1156374.1730396928@sss.pgh.pa.us> <7ec1c65c-1a28-49a7-af43-f77c260a3df6@iki.fi> <1292593.1730399134@sss.pgh.pa.us> <1624905.1730436275@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Fri, 01 Nov 2024 00:44:35 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1637253.1730441792.1@sss.pgh.pa.us> Date: Fri, 01 Nov 2024 02:16:32 -0400 Message-ID: <1637254.1730441792@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > Hmm. So it seems like we could do this: > * Linux, FreeBSD, OpenBSD: do run-time test as recommended > * Windows, macOS: assume that supported ARM hardware can do this > * anything else: assume no hardware CRC Actually, after chewing on that second point awhile longer, how about this modest proposal: * Drop all code for run-time determination of ARM CRC support. Assume it's there unless user builds with a -march option that says it definitely isn't. Realistically, exactly who is going to be running Postgres 18+ on ARM hardware that lacks CRC support? I can think of lots of projects that are more worthy of our time than this. (Perhaps it's time to apply the same mindset to x86 CRC support too?) regards, tom lane