Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lBcNU-00036w-Vb for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Feb 2021 11:49:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lBcNS-0008Vf-Go for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Feb 2021 11:49:18 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lBcNS-0008VY-9x for pgsql-hackers@lists.postgresql.org; Mon, 15 Feb 2021 11:49:18 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lBcNO-0005CK-NJ for pgsql-hackers@postgresql.org; Mon, 15 Feb 2021 11:49:17 +0000 Received: from hnk.local (p2710230-ipbf1703funabasi.chiba.ocn.ne.jp [123.216.93.230]) by oss.nttdata.com (Postfix) with ESMTPSA id D427562617; Mon, 15 Feb 2021 20:49:08 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.3 at oss.nttdata.com Subject: Re: ERROR: invalid spinlock number: 0 To: Michael Paquier , Thomas Munro Cc: pgsql-hackers References: <7ef8708c-5b6b-edd3-2cf2-7783f1c7c175@oss.nttdata.com> <79698f73-7dd7-d9e3-5322-4032b4428653@oss.nttdata.com> From: Fujii Masao Message-ID: <0c58fb4f-3492-c69e-c9fb-56dc252d22fd@oss.nttdata.com> Date: Mon, 15 Feb 2021 20:49:08 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2021/02/15 19:45, Michael Paquier wrote: > On Mon, Feb 15, 2021 at 10:47:05PM +1300, Thomas Munro wrote: >> Why not initialise it in WalRcvShmemInit()? > > I was thinking about doing that as well, but we have no real need to > initialize this stuff in most cases, say standalone deployments. In > particular for the fallback implementation of atomics, we would > prepare a spinlock for nothing. But on second thought, if we make WalRceiverMain() call pg_atomic_init_u64(), the variable is initialized (i,e., SpinLockInit() is called in --disable-atomics) every time walreceiver is started. That may be problematic? If so, the variable needs to be initialized in WalRcvShmemInit(), instead. BTW, the recent commit 46d6e5f567 has the similar issue. The variable that commit added is initialized in InitProcess(), but maybe should be done in InitProcGlobal() or elsewhere. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION