On Tue, 7 Nov 2023 at 14:28, jacktby jacktby <jacktby@gmail.com> wrote:
>
> Hi, postgres hackers, I’m studying postgres buffer cache part. So I open this thread to communicate some buffer cache
codesdesign and try to improve some tricky codes.
>
> For Buffer Cache, we know it’s a buffer array, every bucket of this array is consist of a data page and its header
whichis used to describe the state of the buffer.
>
> For field wait_backend_pgprocno, the comment is "backend of pin-count waiter”, I have problems below:
Did you read the README at src/backend/storage/buffer/README, as well
as the comments and documentation in and around the buffer-locking
functions?
> 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’s try this: we have 5
bufferswith ids (1,2,3,4,5), and they are all in use, now another process with processId 8017 is coming, and it
choosebuffer id 1, so buffer1’s wait_backend_pgprocno is 8017, but later
> buffer4 is released, can process 8017 change to get buffer4? how?
I believe these questions are generally answered by the README and the
comments in bufmgr.c/buf_internal.h for the functions that try to lock
buffers.
> 4. wait_backend_pgprocno is a “integer” type, not an array, why can one buffer be wait by only one process?
Yes, that is correct. It seems like PostgreSQL has yet to find a
workload requires more than one backend to wait for super exclusive
access to a buffer at the same time.
VACUUM seems to be the only workload that currently can wait and sleep
for this exclusive buffer access, and that is already limited to one
process per relation, so there are no explicit concurrent
super-exclusive waits in the system right now.
Kind regards,
Matthias van de Meent
Neon (https://neon.tech)