Hi,
I’ve been trying to review this patch, and it struck me that we’re currently grabbing the content lock exclusively just to flip a header bit:
if (!(buf_state & BM_DIRTY))
{
LWLockAcquire(BufferDescriptorGetContentLock(desc), LW_EXCLUSIVE);
MarkBufferDirty(buf);
LWLockRelease(BufferDescriptorGetContentLock(desc));
}
Since our sole goal here is to simulate a buffer’s dirty state for testing/debugging, I wonder—could we instead:
1. Acquire the shared content lock (which already blocks eviction),
2. Call MarkBufferDirtyHint() to flip the BM_DIRTY bit under the header spinlock, and
3. Release the shared lock?
This seems to satisfy Assert(LWLockHeldByMe(...)) inside the hint routine and would:
- Prevent exclusive‐lock contention when sweeping many buffers,
- Avoid full‐page WAL writes (we only need a hint record, if any)
Would love to hear if this makes sense or or am I overlooking something here. Thanks for any feedback!
Cheers,
Xuneng
Hi,
There is another thread [1] to add both pg_buffercache_evict_[relation
| all] and pg_buffercache_mark_dirty[_all] functions to the
pg_buffercache. I decided to create another thread as
pg_buffercache_evict_[relation | all] functions are committed but
pg_buffercache_mark_dirty[_all] functions still need review.
pg_buffercache_mark_dirty(): This function takes a buffer id as an
argument and tries to mark this buffer as dirty. Returns true on
success.
pg_buffercache_mark_dirty_all(): This is very similar to the
pg_buffercache_mark_dirty() function. The difference is
pg_buffercache_mark_dirty_all() does not take an argument. Instead it
just loops over the shared buffers and tries to mark all of them as
dirty. It returns the number of buffers marked as dirty.
Since that patch is targeted for the PG 19, pg_buffercache is bumped to v1.7.
Latest version is attached and people who already reviewed the patches are CCed.
[1] postgr.es/m/CAN55FZ0h_YoSqqutxV6DES1RW8ig6wcA8CR9rJk358YRMxZFmw%40mail.gmail.com
--
Regards,
Nazir Bilal Yavuz
Microsoft
