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 1rQf6u-002nzA-31 for pgsql-hackers@arkaria.postgresql.org; Fri, 19 Jan 2024 03:00:01 +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 1rQf6t-006ZYM-5z for pgsql-hackers@arkaria.postgresql.org; Fri, 19 Jan 2024 02:59:59 +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 1rQf6s-006ZYE-9e for pgsql-hackers@lists.postgresql.org; Fri, 19 Jan 2024 02:59:58 +0000 Received: from m15.mail.163.com ([45.254.50.219]) by magus.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rQf6m-002ZJX-RU for pgsql-hackers@lists.postgresql.org; Fri, 19 Jan 2024 02:59:57 +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=6Vv1jVJ9ifmMoEw76JMTMKg0ZSZt79u7QFIxbGqNtn0=; b=CdGvGDG0rRlr4t2r8wbKyndMzNGMoTqwTYuJzAdtbSRBo2SufA6HAAxRkDQdom BZsOzmVZhvuJSjIzwHtAUi/sOikR9pWJ+dGz95OrSCLbYCKV/okrn5HinGVUtMwj 7vTAEFrxRCeyW/E+YAr4/TSoeezWeqvVZEggaZ6ZdvgGk= Received: from b97369165980 (unknown [140.205.118.149]) by zwqz-smtp-mta-g1-3 (Coremail) with SMTP id _____wD3X2mY5allNCZ6BQ--.28951S3; Fri, 19 Jan 2024 10:59:37 +0800 (CST) References: <87plyhvama.fsf@163.com> <489987.1704381735@sss.pgh.pa.us> <498328.1704386013@sss.pgh.pa.us> <20240104225403.dgmbbfffmm3srpgq@awork3.anarazel.de> <871qaso7ub.fsf@163.com> <87sf37mdqq.fsf@163.com> <87o7dum084.fsf@163.com> <87h6jkmucz.fsf@163.com> <8734uz17va.fsf@163.com> <87o7diyf3z.fsf@163.com> <87edeexznn.fsf@163.com> User-agent: mu4e 1.10.7; emacs 29.1 From: Andy Fan To: Robert Haas Cc: Matthias van de Meent , Andres Freund , Tom Lane , Thomas Munro , pgsql-hackers@lists.postgresql.org Subject: Re: the s_lock_stuck on perform_spin_delay Date: Fri, 19 Jan 2024 10:51:43 +0800 In-reply-to: Message-ID: <87a5p2xc2v.fsf@163.com> MIME-Version: 1.0 Content-Type: text/plain X-CM-TRANSID: _____wD3X2mY5allNCZ6BQ--.28951S3 X-Coremail-Antispam: 1Uf129KBjvJXoW7GFWrGw47Cw1fAr18uFW8Crg_yoW8Jrykp3 4rKF42yr1kXF4Ivwsa9r48Zr4ayF4rJ3WYk3s5Ar97ArWUGFySvryruw43uFWDZrnxGa43 Zr4jk397GF9Y9FJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0zRpwZ3UUUUU= X-Originating-IP: [140.205.118.149] X-CM-SenderInfo: x2klx3xlid0iqsrtqiywtou0bp/1tbiQB9qU2VOBHvbTAAAsl List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, Here is the summary of the open-items, it would be great that Andres and Matthias have a look at this when they have time. 1. Shall we treat the LockBufHdr as a SpinLock usage. >> The LockBufHdr also used init_local_spin_delay / perform_spin_delay >> infrastruce and then it has the same issue like ${subject}, it is pretty >> like the code in s_lock; Based on my current knowledge, I think we >> should add the check there. > > I'd like to hear from Andres, if possible. @Andres: Should these > sanity checks apply only to spin locks per se, or also to buffer > header locks? > 2. Where shall we put the START/END_SPIN_LOCK() into? Personally I'd like spin.h. One of the reasons is 'misc' usually makes me think they are something not well categoried, and hence many different stuffs are put together. >> they were put into spin.h in v1 but later move to miscadmin.h at [1]. >> [1] >> https://www.postgresql.org/message-id/CAEze2WggP-2Dhocmdhp-LxBzic%3DMXRgGA_tmv1G_9n-PDt2MQg%40mail.gmail.com > > I'm not entirely sure what the right thing to do is here, and the > answer may depend on the previous question. But I disagree with > Matthias -- I don't think miscadmin.h can be the right answer > regardless. > -- Best Regards Andy Fan