Re: [PATCH] bufmgr: tighten LWLock:BufferMapping on InvalidateBuffer

Hi Alexandre,

Thanks for sharing the experiments. I have a few concerns.

The benchmark runs in a single backend. This mainly measures instruction and
branch overhead. Saving a few nanoseconds here does not necessarily result
in a measurable end-to-end improvement.

The patch also adds more interfaces and makes the locking code harder to use
and maintain. Some changes seem to move costs rather than remove them.

In 0002, LWLockAcquire is declared as a non-static inline function, while its
external definition is removed, when the compiler does not inline it, for
example with -O0, this whill leave an unresolved LWLockAcquire symbol and
causes a link failure:
```C
inline bool LWLockAcquire(LWLock *lock, LWLockMode mode)
```

In 0005, queued is not initialized and is never set to true after queueing,
This can cause repeated queueing, incorrect dequeueing, or prevent the backend
from reaching the normal sleep path:
```C
bool queued;

if (!queued)
{
LWLockQueueSelf(lock, mode);
continue;
}
```

I think it would be more useful to reduce unnecessary LWLock acquisitions or
contention in higher-level code paths, such as buffer mapping and WAL buffers.
For LWLock itself, the important part are atomic operations and cache-line
contention (though there might be no lock contention, but at CPU level, emmm),
wait-list contention, sleep/wakeup mechanism, and fairness...

Best Regards,
Yuhang Qiu.