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.96) (envelope-from ) id 1vQQaZ-007HM1-1J for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Dec 2025 13:38:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vQQaY-0080LJ-1i for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Dec 2025 13:38:42 +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.96) (envelope-from ) id 1vQQaY-0080L9-0T for pgsql-hackers@lists.postgresql.org; Tue, 02 Dec 2025 13:38:42 +0000 Received: from lahtoruutu.iki.fi ([2a0b:5c81:1c1::37]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vQQaW-002k2q-1w for pgsql-hackers@postgresql.org; Tue, 02 Dec 2025 13:38:42 +0000 Received: from [10.0.2.15] (unknown [130.41.208.2]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: hlinnaka) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 4dLML355tMz49PwQ; Tue, 02 Dec 2025 15:38:35 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1764682716; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Vq3SEL7WFBHdt/c9mqpy3zXC0+J031L06A8A+sT0elY=; b=DsHIMIrlIz3fjBodE6oL1cEqi037dJt9OC95lHb1DOqmZnO5JwNE9e2kzfRedi//B3Ksxj OCQT7jlm5D3Y5z8Q1LvVQZHhJyr+t3uWCQnt+acCFekyLFOEsOSQw0aLVcYTl7xy/+MDID LuLOPYk4gjMOiSFek/XheN4Mxy7v18x4fwzLlvu56w/Vrb/wMtsh3ghQ652igzf2SZuOD/ /IYKIvAsITaIIqUjmS9X0Ap7CQZMgFGJx+Xe1riSeak60FORblv+4bF7m+jHCbHKjFT+9B j5OUX5hhcpoNAGFMYMZdxW+YifgrTJkTMJc9MQjMbFmGfe4qxjUgxZbhju39Kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1764682716; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Vq3SEL7WFBHdt/c9mqpy3zXC0+J031L06A8A+sT0elY=; b=VaDPHXOiegXYnI4PMq460PFEyktsXTleW1lZsvlFQO1O5boUOAocpXSMq+RAJvtFaA6uF6 3GpvHUTQj37ieb9NjrSr4bKZ1DR3Tcpau6mZDUdbw9wMu4TKK4agqU4hqvr9J1EAW2fMGR Pd911x4xGRimkSPl4n5HsSvPDBezVLY6lOhRpjn8NnP8tbdP10XwgsR0IRfY48BzfzbFrL b3iHVi8ffE91004ix25Q0kfdGhvZhYWlL9gJB3BVOWLVKE/6wDR9397ibH1sxHY4tMGabC MQrwzrm7Xsr09sfLke4nrzBhlekjIfQi2AmJbyMhpFM3tX2m7XPnIw4xNN/V4g== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=hlinnaka smtp.mailfrom=hlinnaka@iki.fi ARC-Seal: i=1; a=rsa-sha256; d=iki.fi; s=lahtoruutu; cv=none; t=1764682716; b=DGPr30f7Yf8jFxQ2zkBg8j03Z1Op1YZhmz8IWvzfuf36a0987b9wcQ6Q4fgTXWexq3R9lZ AOMSmptvXyxOlJfzCsn50yrs6Y/VB/yVb1N43kZOEcOKpmvSFGBlmHLE67ivwWI9eU141I J+LMNfai/x6ak0WU5LC1K+kGX6UKm0Y4nBBPVXTh01KGz1UsZ9KZqD8XjzxwNBPTEcRFiA ySOAy8FlWD3clrw/2BH3o7bYbw9/FaHEXnZN0PTPwWgUzVA6BHrkC0jH4oQumgg0N5qzeh QWNunMpuDsnMsVmRisXkDUIYs1wliwRX/PM7HwAaGIe9svvKLsw7Eu8FHDi2BA== Message-ID: <8926bc6a-cab3-4edf-acf2-02b4cbeb7c9b@iki.fi> Date: Tue, 2 Dec 2025 15:38:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Buffer locking is special (hints, checksums, AIO writes) To: Andres Freund Cc: Melanie Plageman , Matthias van de Meent , pgsql-hackers@postgresql.org, Thomas Munro , Noah Misch , Robert Haas , Michael Paquier References: <3je3ahgf7rrmmurxo6hnlhg5d3ffwfrtjwjxd6jm5srlv5iebp@vxqk5qtgmowr> <3w7v3w6a57jnssokap4k7thoekig72flnyhd4wp3yftzdd7lm7@f6lpcfen6hr7> <6rgb2nvhyvnszz4ul3wfzlf5rheb2kkwrglthnna7qhe24onwr@vw27225tkyar> <3nce7i72ayzkunai6mkz24ckbxk74jodz4ua2chcdrwppxlxcd@w6x5kfkjrkru> Content-Language: en-US From: Heikki Linnakangas In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 02/12/2025 15:20, Andres Freund wrote: > On 2025-12-02 10:01:06 +0200, Heikki Linnakangas wrote: >> But speaking of that: why do we not allow two processes to concurrently set >> hint bits on a page anymore? > > It'd make the locking a lot more complicated without much of a benefit. > > The new share-exclusive lock mode only requires one additional bit of lock > state, for the single allowed holder. If we wanted a new lockmode that > prevented the page from being written out concurrently, but could be held > multiple times, we'd need at least MAX_BACKENDS bits for the lock level > allowing hint bits to be set and another lock level to acquire while writing > out the buffer. > > At the same time, there seems to be little benefit in setting hint bits on a > page concurrently. A very common case is that the same hint bit(s) would be > set by multiple backends, we don't gain anything from that. And in the cases > where hint bits were intended to be set for different tuples, the window in > which that is not allowed is very narrow, and the cost of not setting right in > that moment is pretty small and the cost of not setting the hint bit right > then and there isn't high. > > Makes sense? Yep, makes sense. Would be good to put that in a comment somewhere, and in the commit message. "We could allow multiple backends to set hint bits concurrently, but it'd make the lock implementation more complicated" - Heikki