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 1r0M88-005BVx-Vt for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Nov 2023 13:28:33 +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 1r0M87-008Oha-1I for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Nov 2023 13:28:31 +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 1r0M86-008OhR-HD for pgsql-hackers@lists.postgresql.org; Tue, 07 Nov 2023 13:28:30 +0000 Received: from mail-pl1-x642.google.com ([2607:f8b0:4864:20::642]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1r0M84-004P1A-1H for pgsql-hackers@lists.postgresql.org; Tue, 07 Nov 2023 13:28:29 +0000 Received: by mail-pl1-x642.google.com with SMTP id d9443c01a7336-1ca85ff26afso10976875ad.1 for ; Tue, 07 Nov 2023 05:28:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699363707; x=1699968507; darn=lists.postgresql.org; h=to:date:message-id:subject:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=VfpLfLVyikOPCpxdxttwgtx56VrQP27V4cS9sIkO9e4=; b=RDl5TIEyM+Z9fZTftfl81uJEMvsEJnGpY6cVoFTV4s5I8r6FjH5ToB31rmfmYfiSdk SoTg3UEZzQOg86n/ahUlgMu3kD/PeRksSDdVek4jzImdvNMfv/T6N1s3yURKq7i6tidy 0a9fldo1kE0FayNdyxuiZSqnAAmyebvJU5GPwvdj9bxQs6+TcmRn1nMl8jJQKcv8W2M6 0JKP3DMjZgFGm66g0H02XaqLLlxh0gf4fWjjzbrNxxX6+o0hlfvfbi1vYssLCJtL1xsH yLhpkYVUDoS9LMH1+srGyT1/dOy36dy0hZqQcwk9qgKuMTyiBafGNA5dFsr8ZJ9flg7K D1/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699363707; x=1699968507; h=to:date:message-id:subject:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=VfpLfLVyikOPCpxdxttwgtx56VrQP27V4cS9sIkO9e4=; b=hpbSarly50dBKLCafbtKEm2iDP8+9C8qilgOAb+DSdwDT+jx4bTgYzabajNJEid9xn Ha6oYVnfkbT+f8shR42YCgaqI5EOlLKd8DUS6BMf4zDVtfm0eompG9kCBSsUVBFFbYeD PySayJcvfy2klVH9djFDqxMQEwnGiun1FOexF9NaUzos+hrCOtc0VUfaokh07tXVh3JS p6WgDsGR81e2oyTSHajGi/GMEhPmqvJbLZtwdwzBMsnTjfZt28dK5zHI8CHaofRmMi+L SD3OeRkdH5frNpgEcGhA1BhivMYurc+Q4ZYs4zHYUz6kv/EqTSadUTzH5KsaSKYH6XZV D0GA== X-Gm-Message-State: AOJu0Ywhf4zltImstyOwfX4l3VfLNAS4RO1ngKVw1gAMwq+I7cbIF3uH XrWtQ6nFJFUpy/7i+flLqYYb1/dQEeV97HBL X-Google-Smtp-Source: AGHT+IGhOf5O0AW2/CIexdiVUUD40Us3pfiIkBwJLcLIGJg1XsaEjGJFr4rrYLv/qz2gzQP+JN+ezg== X-Received: by 2002:a17:903:3406:b0:1cc:3b88:78b with SMTP id ke6-20020a170903340600b001cc3b88078bmr25563829plb.6.1699363706143; Tue, 07 Nov 2023 05:28:26 -0800 (PST) Received: from smtpclient.apple ([2406:da14:367:5600:cd95:be04:a0a7:13a4]) by smtp.gmail.com with ESMTPSA id e2-20020a170902d38200b001c8836a3795sm7641852pld.271.2023.11.07.05.28.25 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Nov 2023 05:28:25 -0800 (PST) From: jacktby jacktby Content-Type: multipart/alternative; boundary="Apple-Mail=_1A07EA62-5245-4193-91A1-577394311720" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Buffer Cache Problem Message-Id: <059DE243-F4B0-41CC-84BE-9362FC5FB99A@gmail.com> Date: Tue, 7 Nov 2023 21:28:12 +0800 To: pgsql-hackers@lists.postgresql.org X-Mailer: Apple Mail (2.3731.600.7) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --Apple-Mail=_1A07EA62-5245-4193-91A1-577394311720 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, postgres hackers, I=E2=80=99m studying postgres buffer cache part. = So I open this thread to communicate some buffer cache codes design and = try to improve some tricky codes. For Buffer Cache, we know it=E2=80=99s a buffer array, every bucket of = this array is consist of a data page and its header which is used to = describe the state of the buffer.=20 This is the origin code of buffer header: typedef struct BufferDesc { BufferTag tag; /* ID of page contained = in buffer */ int buf_id; /* buffer's = index number (from 0) */ /* state of the tag, containing flags, refcount and usagecount = */ pg_atomic_uint32 state; int wait_backend_pgprocno; /* backend of = pin-count waiter */ int freeNext; /* link in = freelist chain */ LWLock content_lock; /* to lock access to buffer = contents */ } BufferDesc; For field wait_backend_pgprocno, the comment is "backend of pin-count = waiter=E2=80=9D, I have problems below: 1. it means which processId is waiting this buffer, right?=20 2. and if wait_backend_pgprocno is valid, so it says this buffer is in = use by one process, right? 3. if one buffer is wait by another process, it means all buffers are = out of use, right? So let=E2=80=99s try this: we have 5 buffers with ids = (1,2,3,4,5), and they are all in use, now another process with = processId 8017 is coming, and it choose buffer id 1, so buffer1=E2=80=99s= wait_backend_pgprocno is 8017, but later buffer4 is released, can process 8017 change to get buffer4? how? 4. wait_backend_pgprocno is a =E2=80=9Cinteger=E2=80=9D type, not an = array, why can one buffer be wait by only one process? Hope your reply, thanks!! I=E2=80=99m willing to do contributions after = I study buffer cache implementations.= --Apple-Mail=_1A07EA62-5245-4193-91A1-577394311720 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, postgres = hackers, I=E2=80=99m studying postgres buffer cache part. So I open this = thread to communicate some buffer cache codes design and try to improve = some tricky codes.

For Buffer Cache, we know it=E2=80=99= s a buffer array, every bucket of this array is consist of a data page = and its header which is used to describe the state of the = buffer. 

This is the origin code of buffer = header:
typedef struct = BufferDesc
{
BufferTag tag; = /* ID of page contained in buffer */
int = buf_id; = /* buffer's index number (from 0) = */

/* state of the tag, containing = flags, refcount and usagecount */
pg_atomic_uint32 = state;

int = wait_backend_pgprocno; /* backend of pin-count waiter = */
= int = freeNext; /* link in freelist chain = */
= LWLock = content_lock; /* to lock access to buffer = contents */
} BufferDesc;

For = field wait_backend_pgprocno, the comment is "backend of = pin-count waiter=E2=80=9D, I have = problems below:
1. it means = which processId is waiting this buffer, = right? 
2. and = if wait_backend_pgprocno is valid, so it says this buffer is in use = by one process, right?
3. if one buffer is wait by another process, it means = all buffers are out of use, right? So let=E2=80=99s try this: we have 5 = buffers with ids (1,2,3,4,5), and they  are all in use, now another = process  with processId 8017 is coming, and it choose buffer id 1, = so  buffer1=E2=80=99s wait_backend_pgprocno is 8017, but = later
buffer4 is released, can process 8017 change to get = buffer4? how?
4. wait_backend_pgprocno is a =E2=80=9Cinteger=E2=80= =9D type, not an array, why can one buffer be wait by only = one process?

Hope your reply, thanks!! I=E2=80=99m willing to = do contributions after I = study buffer cache implementations.
= --Apple-Mail=_1A07EA62-5245-4193-91A1-577394311720--