Subject: Re: Buffer Cache Problem

From: jacktby jacktby <[email-masked]>
Date: Fri, 10 Nov 2023 22:38:57 +0800

> 2023年11月10日 22:31，jacktby jacktby <[email-masked]> 写道：
> 
> In the bus_internal.h,I see
> ====================================================
>  Note: Buffer header lock (BM_LOCKED flag) must be held to examine or change  tag, state or wait_backend_pgprocno fields.
> ====================================================
> As we all know, this buffer header lock is implemented by a bit in state filed, and this state field is a atomic_u32 type, so in fact we don’t need to 
> hold buffer lock when we update state, this comment has error，right?
Oh, sorry this is true, in fact we never acquire a spin lock when update the state.

---

From: jacktby jacktby <[email-masked]>
Date: Sat, 11 Nov 2023 00:46:13 +0800

Hi, I have 3 questions here:
1. I see comments in but_internals.h below:
========================================
 * Also, in places we do one-time reads of the flags without bothering to
 * lock the buffer header; this is generally for situations where we don't
 * expect the flag bit being tested to be changing.
========================================
In fact, the flag is in state filed which is an atomic_u32, so we don’t need to acquire buffer header lock in any case, but for this comment, seems it’s saying we need to hold a buffer header lock when read flag in general.

2. Another question:
========================================
 * We can't physically remove items from a disk page if another backend has
 * the buffer pinned.  Hence, a backend may need to wait for all other pins
 * to go away.  This is signaled by storing its own pgprocno into
 * wait_backend_pgprocno and setting flag bit BM_PIN_COUNT_WAITER.  At present,
 * there can be only one such waiter per buffer.
========================================
The comments above,  in fact for now, if a backend plan to remove items from a disk page, this is a mutation operation, so this backend must hold a exclusive lock for this buffer page, then in this case, there are no other backends pinning this buffer, so the pin refcount must be 1 (it’s by this backend), then this backend can remove the items safely and no need to wait other backends (because there are no other backends pinning this buffer). So my question is below:
 The operation “storing its own pgprocno into
 * wait_backend_pgprocno and setting flag bit BM_PIN_COUNT_WAITER” is whether too expensive, we should not do like this, right?

3. Where is the array?
========================================
 * Per-buffer I/O condition variables are currently kept outside this struct in
 * a separate array.  They could be moved in here and still fit within that
 * limit on common systems, but for now that is not done.
========================================