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 1ur0Ay-00GcY8-Dm for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Aug 2025 20:21:53 +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 1ur0Ax-009v3T-RR for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Aug 2025 20:21:52 +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 1ur0Ax-009v3L-HR for pgsql-hackers@lists.postgresql.org; Tue, 26 Aug 2025 20:21:52 +0000 Received: from mail-ej1-x62e.google.com ([2a00:1450:4864:20::62e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1ur0Av-001tlu-18 for pgsql-hackers@postgresql.org; Tue, 26 Aug 2025 20:21:50 +0000 Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-afebb6d4093so68512466b.1 for ; Tue, 26 Aug 2025 13:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756239708; x=1756844508; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ahi7U5f2TE5jqEfb9Rh5Mvrk7ji+Z457KvmGjfNWvow=; b=Si8vhH88kXeOO6TQVWJugkwjRjZ1Ljo4TZPivseZKgUSY+3ECNPOD1LSu4NOckFGds 5O9pr4Zx0/TeehSJnK7rVi7BmAPU2i3DJll2HBfKw5OFUp3TFrl5qC4wuLA8XXDwksPS 7X/Y3XezuYZIY44qy0gdsKnGnhyTp1hYkjFfGmpBqn8a+FUT0UU2M8Ssisc/gcSBsK9k xQljvCUttZMIz7sXA5sfanciZ6SlDJskgtiBgNIr16ZfXmyJzX1a4qIK9tb28ev1WwrI buqM+jtaWyJayUvKbfPpOtXRjuLHeI08O6xmIcFMXRCtoC2cWP1tCRRxTaWZcefyvA8a b5mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756239708; x=1756844508; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ahi7U5f2TE5jqEfb9Rh5Mvrk7ji+Z457KvmGjfNWvow=; b=c+0ihsmw4fkwmJC1h2jbwCCEe9R6y3baOU3PIZfTFSBLgXnwF5xgeTJ7DkkwNyylDE 42Mw8t05UfVRRB8ZiB4t++jUMQIIdSR2RwZDvCV7cYJVK6mIt3HLE38T+Du65ulLvUVQ t/ExTV8sV/HhSYNVLCZyN1HvK1QSweG8L+zI1KRQ/6LA0EstjWGxGYEffzpvQApatTrx uqpVeitLc8+/7LBxtyDHeh0jcJTRuO5tlirNPCCZOnsBfA8XyJGQoiRCBttqlYNl7Uwo TZQkQ8DE9wa+J3PSKMyIHqI5lRNocOUb/hU+iupDxS5wwNJN2SDEOyYalhpabGzASdOk rFOw== X-Gm-Message-State: AOJu0YxXOcL2IuGEigitkmr7e6u5d6cDcuuNqg9T39GkdkcoCGEXAFge 7ekNNzBBHEo0k8K27o5NKTr3Tz3AjRjpGTavjAZCzBfOFJnUQw7OI0741OHnIWn8NL5YoGYA3et 2hRGF+GVcJxJzpOOIVyJ9wv66JM79mPk= X-Gm-Gg: ASbGncty89jUWJZJxmewYwlFqs3louTUq6LZ+ECwCrd/QwI69cCwzxea43hvVKdi07N yk9rhjf21TPM3bMEpjE9pLvkhLtvVroWJjhAClF5bpYsfsN3Ytw+aaH/cjfz/oMqDgp+8aQCKwm CwpazAbwQ7a9vu/eLrX19+MPavJU18XTQg881RCWWsrZo5UQ3UCT8tBQBgHRnKG9Qm8eUrbsDIx ok7EeEQppwsvoIFmlYyFMovOuZDKgoQESJ1pC9P X-Google-Smtp-Source: AGHT+IHeoqL5z0VEwOgUErbVBmhjromO2OMqbcwAeqUPaOQiD3WCVS18BjkvQ4/dTAQyipXFGFNkiGb/YvTC5WN9t2o= X-Received: by 2002:a17:907:6d1f:b0:af9:71c2:9f7 with SMTP id a640c23a62f3a-afe28ffbfd9mr1598957566b.2.1756239708356; Tue, 26 Aug 2025 13:21:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Haas Date: Tue, 26 Aug 2025 16:21:36 -0400 X-Gm-Features: Ac12FXwLjcQRg3TTexQ6bJv0b6yd_zRBwth6D7QALGy-LViZTwlHqJO90AlOLBY Message-ID: Subject: Re: Buffer locking is special (hints, checksums, AIO writes) To: Andres Freund Cc: pgsql-hackers@postgresql.org, Melanie Plageman , Thomas Munro , Heikki Linnakangas , Noah Misch Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Aug 22, 2025 at 3:45=E2=80=AFPM Andres Freund = wrote: > My conclusion from the above is that we ought to: > > A) Make Buffer Locks something separate from lwlocks > B) Merge BufferDesc.state and the content lock > C) Allow some modifications of BufferDesc.state while holding spinlock +1 to (A) and (B). No particular opinion on (C) but if it works well, great= . > The order of changes I think makes the most sense is the following: > > 1) Allow some modifications while holding the buffer header spinlock > 2) Reduce buffer pin with just an atomic-sub > 3) Widen BufferDesc.state to 64 bits > 4) Implement buffer locking inside BufferDesc.state > 5) Do IO while holding share-exclusive lock and require all buffer > modifications to at least hold share exclusive lock > 6) Wait for AIO when acquiring an exclusive content lock No strong objections. I certainly like getting to (5) and (6) and I think those are in the right order. I'm not sure about the rest. I thought (1) and (2) were the same change after reading your email; and it surprises me a little bit that (2) is separate from (4). But I'm sure you have a much better sense of this than I do. > DOES ANYBODY HAVE A BETTER NAME THAN SHARE-EXCLUSIVE???!? AFAIK "share exclusive" or "SX" is standard terminology. While I'm not wholly hostile to the idea of coming up with something else, I don't think our tendency to invent our own way to do everything is one of our better tendencies as a project. --=20 Robert Haas EDB: http://www.enterprisedb.com