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 1sOD4S-00D1W2-PG for pgsql-hackers@arkaria.postgresql.org; Mon, 01 Jul 2024 09:11:37 +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 1sOD3Q-00HLgP-Sd for pgsql-hackers@arkaria.postgresql.org; Mon, 01 Jul 2024 09:10:33 +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.94.2) (envelope-from ) id 1sOD3P-00HLf1-Su for pgsql-hackers@lists.postgresql.org; Mon, 01 Jul 2024 09:10:32 +0000 Received: from fhigh4-smtp.messagingengine.com ([103.168.172.155]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sOD3N-0040JW-5P for pgsql-hackers@lists.postgresql.org; Mon, 01 Jul 2024 09:10:30 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfhigh.nyi.internal (Postfix) with ESMTP id C6613114024E; Mon, 1 Jul 2024 05:10:27 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 01 Jul 2024 05:10:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1719825027; x= 1719911427; bh=a/sLXuhI0vcbDMdavY8iUwQdmpA8b8NeoEbWcrwdukQ=; b=r 60oh8SERX9gw7xdryteIUAeJG5d8L9Hzzyrih0vUmfIAHcg5RTEiTuF5uBamtvXs x01WOsuGQ5ZWIoSYLIyT2hPyRe/MDApC1R97EqCl/CQxnJhMt6toKWBbOpx0gq3m W2JSV2vl+V8g6ujBs0kaZFjIlerVYuz1CxXvb5Ii7BbaLFm+w8yndxLup39hW8Ue yrxWytx2qjUm8obI69ctGzdT5T7mjDtDcw7EssUTMnLGXQ+7diN19C9GUOZq2/AE dgLJPLmAyc/2TuxOxC/L2rzkPoV+apPSXQSSdU9A8kN6tyQxRAZd9BFnVPlNIbXq fAwuMUsXP43t1qs26sqsQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudefgdduvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfggtggugfgjsehmkeerredttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpeduleekkefgtddttedtkefguddvieffleetgeejiefhteeh keevfeettdduvdfhueenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 1 Jul 2024 05:10:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alvh.no-ip.org; s=schmee; t=1719825024; bh=s/KK5w5FKypm+9gLk/WTpkBul0tM8FRmiQF8hbVOZXg=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=ZEdDmOAoC+ld6OFLtfO70xPsctkGZg785ERwgijri5JxCZ+f/kOKeTV3W1fczIr9R NkLHr9oqH9GX5WJUr+zHwudSCXYP/QfgfgmTHHBpjnnLUL1jablQSOGpxPEqtdn/Yb aNO++5x3RwlFGI8IBt0QrEe0GKkfM/4L0JTB9TrEaVgA6UHTjOTqDhhmnmQXfl5h8Z G2kjso+Bl99da2DmYD64Gz8jz9/KOrEMi4zFbkp/kF4Dasnw+5RR7gSELbHGNWspYG sZH0p9IXmehDxmAwqzszEYzWCnfj8CuPViBLf7JKtygrO2LKEKCUvKTQy1B9vIqXF6 vkG27D8IIYSCA== Received: by schmee.alvh.no-ip.org (Postfix, from userid 1000) id 63D3F52B; Mon, 1 Jul 2024 02:10:24 -0700 (PDT) Date: Mon, 1 Jul 2024 11:10:24 +0200 From: Alvaro Herrera To: Alexander Lakhin Cc: Bharath Rupireddy , Tom Lane , Andres Freund , Jeff Davis , pgsql-hackers@lists.postgresql.org, Jaime Casanova Subject: Re: LogwrtResult contended spinlock Message-ID: <202407010910.ktykqkc52ffb@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="fe7nlxqhseziub3f" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4244f22a-a208-321f-ec32-150ffde35c8e@gmail.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --fe7nlxqhseziub3f Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello, On 2024-Jun-29, Alexander Lakhin wrote: > It doesn't, but the following works for me: >  static inline uint64 >  pg_atomic_monotonic_advance_u64(volatile pg_atomic_uint64 *ptr, uint64 target_) >  { > -       uint64          currval; > +       pg_attribute_aligned(8) uint64          currval; > > because the failed assertion is: > #ifndef PG_HAVE_ATOMIC_U64_SIMULATION >     AssertPointerAlignment(&currval, 8); > #endif Hah, thank you. In the meantime I noticed that pg_attribute_aligned() is not supported in every platform/compiler, so for safety sake I think it's better to go with what we do for PGAlignedBlock: use a union with a double member. That should be 8-byte aligned on x86 as well, unless I misunderstand. BTW if things works after this fix, I suggest you get a buildfarm member running with this configuration. Otherwise it's quite likely that we'll break it again. Or we could just decide we don't care about this particular platform ... but AFAICS the buildfarm does have other 32-bit animals running. [ looks at buildfarm ] Oh! while looking at Adder's config, I noticed this line: Checking for alignment of "double" : 4 So, I do misunderstand doubles. So my patch is not going to work. There seems to be nothing that has alignment 8 there, so I guess we're back to using pg_attribute_aligned() and abort the compile if that doesn't exist. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "La gente vulgar sólo piensa en pasar el tiempo; el que tiene talento, en aprovecharlo" --fe7nlxqhseziub3f Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v2-0001-Fix-alignment-of-variable-in-pg_atomic_monotonic_.patch" From 9d240e90f87bf8b53bd5d92b623e33419db64717 Mon Sep 17 00:00:00 2001 From: Alvaro Herrera Date: Mon, 1 Jul 2024 10:41:06 +0200 Subject: [PATCH v2] Fix alignment of variable in pg_atomic_monotonic_advance_u64 Reported-by: Alexander Lakhin Discussion: https://postgr.es/m/36796438-a718-cf9b-2071-b2c1b947c1b5@gmail.com --- src/include/port/atomics.h | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/src/include/port/atomics.h b/src/include/port/atomics.h index 78987f3154..964732e660 100644 --- a/src/include/port/atomics.h +++ b/src/include/port/atomics.h @@ -580,30 +580,38 @@ pg_atomic_sub_fetch_u64(volatile pg_atomic_uint64 *ptr, int64 sub_) static inline uint64 pg_atomic_monotonic_advance_u64(volatile pg_atomic_uint64 *ptr, uint64 target_) { - uint64 currval; + /* + * On 32-bit machines, declaring a bare uint64 variable doesn't promise + * the alignment we need, so coerce the compiler this way. + */ + union + { + uint64 u64; + double force_align_d; + } currval; #ifndef PG_HAVE_ATOMIC_U64_SIMULATION AssertPointerAlignment(ptr, 8); #endif - currval = pg_atomic_read_u64_impl(ptr); - if (currval >= target_) + currval.u64 = pg_atomic_read_u64_impl(ptr); + if (currval.u64 >= target_) { pg_memory_barrier(); - return currval; + return currval.u64; } #ifndef PG_HAVE_ATOMIC_U64_SIMULATION - AssertPointerAlignment(&currval, 8); + AssertPointerAlignment(&currval.u64, 8); #endif - while (currval < target_) + while (currval.u64 < target_) { - if (pg_atomic_compare_exchange_u64_impl(ptr, &currval, target_)) + if (pg_atomic_compare_exchange_u64_impl(ptr, &currval.u64, target_)) break; } - return Max(target_, currval); + return Max(target_, currval.u64); } #undef INSIDE_ATOMICS_H -- 2.39.2 --fe7nlxqhseziub3f--