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 1rMfkU-005rgI-WE for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Jan 2024 02:52:23 +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 1rMfkS-001Zlr-Gg for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Jan 2024 02:52:20 +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 1rMfkR-001Zka-Lq for pgsql-hackers@lists.postgresql.org; Mon, 08 Jan 2024 02:52:20 +0000 Received: from m15.mail.163.com ([45.254.50.220]) by makus.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rMfkI-000PhU-Uv for pgsql-hackers@lists.postgresql.org; Mon, 08 Jan 2024 02:52:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:Subject:Date:Message-ID:MIME-Version: Content-Type; bh=tWjlmLc0Y11qdxvylQN+LhWyhrcpO4dIGK+zy+c7uFs=; b=qAJOv5+ksoHZsh2hX7tyRhPmBEoU4rOtK3lF4+1ULrkX+Qj8VsvF8Rat7N+ACG IurdweR0Rf+fdBM4FCCMxuQ0aK7IaP6Y9b870Y1Ea/mP3gY8BeU61B2r9wo5siSV aL6UUMyEuDwzGftXFnZINe+8JAHuVHbXAut5LohwCO+g8= Received: from b97369165980 (unknown [140.205.118.166]) by zwqz-smtp-mta-g1-1 (Coremail) with SMTP id _____wD3XxdMY5tlTEZOAg--.42135S3; Mon, 08 Jan 2024 10:51:57 +0800 (CST) References: <87plyhvama.fsf@163.com> <489987.1704381735@sss.pgh.pa.us> <498328.1704386013@sss.pgh.pa.us> <20240104225403.dgmbbfffmm3srpgq@awork3.anarazel.de> User-agent: mu4e 1.10.7; emacs 29.1 From: Andy Fan To: Andres Freund Cc: Robert Haas , Tom Lane , Thomas Munro , pgsql-hackers@lists.postgresql.org Subject: Re: the s_lock_stuck on perform_spin_delay Date: Mon, 08 Jan 2024 10:41:01 +0800 In-reply-to: <20240104225403.dgmbbfffmm3srpgq@awork3.anarazel.de> Message-ID: <871qaso7ub.fsf@163.com> MIME-Version: 1.0 Content-Type: text/plain X-CM-TRANSID: _____wD3XxdMY5tlTEZOAg--.42135S3 X-Coremail-Antispam: 1Uf129KBjvJXoW7Zw48uF13XF1UJw1rCw1kGrg_yoW8GrW5pF Wku3yYkrykJF1FvFn5X3W7K3yfCw4rGrW5Crn7Ka9xAw12g3sayFn8tFWjvas5GrnYgr4U Xa17KryUur1UZFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0zR-o7iUUUUU= X-Originating-IP: [140.205.118.166] X-CM-SenderInfo: x2klx3xlid0iqsrtqiywtou0bp/xtbBzxBfU2V4HOnsfgAAsp List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi! > > I think we should add cassert-only infrastructure tracking whether we > currently hold spinlocks, are in a signal handler and perhaps a few other > states. That'd allow us to add assertions like: .. > - no lwlocks or ... while in signal handlers I *wish* lwlocks should *not* be held while in signal handlers since it inspired me for a direction of a low-frequency internal bug where a backend acuqire a LWLock when it has acuqired it before. However when I read more document and code, I am thinking this should not be a problem. per: src/backend/storage/lmgr/README """ LWLock manager will automatically release held LWLocks during elog() recovery, so it is safe to raise an error while holding LWLocks. """ The code shows us after we acquire a LWLock, such information will be added into a global variable named held_lwlocks, and whenever we want to release all the them, we can just call LWLockReleaseAll. LWLockReleaseAll is called in AbortTransaction, AbortSubTransaction, ProcKill, AuxiliaryProcKill and so on. the code is same with what the README said. So suppose we have some codes like this: LWLockAcquire(...); CHECK_FOR_INTERRUPTS(); LWLockRelease(); Even we got ERROR/FATAL in the CHECK_FOR_INTERRUPTS, I think the LWLock are suppose to be released because of the above statement. Am I missing anything? -- Best Regards Andy Fan