Re: [Patch] Optimize dropping of relation buffers using dlist

On Tue, Dec 22, 2020 at 7:13 AM tsunakawa.takay@fujitsu.com
<tsunakawa.takay@fujitsu.com> wrote:
>
> From: Amit Kapila <amit.kapila16@gmail.com>
> > This answers the second part of the question but what about the first
> > part (We hold a buffer partition lock, and have done a lookup in th
> > mapping table. Why are we then rechecking the
> > relfilenode/fork/blocknum?)
> >
> > I think we don't need such a check, rather we can have an Assert
> > corresponding to that if-condition in the patch. I understand it is
> > safe to compare relfilenode/fork/blocknum but it might confuse readers
> > of the code.
>
> Hmm, you're right. I thought someone else could steal the found buffer and use it for another block because the
buffermapping lwlock is released without pinning the buffer or acquiring the buffer header spinlock.
 
>

Okay, I see your point.

>  However, in this case (replay of TRUNCATE during recovery), nobody steals the buffer: bgwriter or checkpointer
doesn'tuse a buffer for a new block, and the client backend waits for AccessExclusive lock.
 
>
>

Why would all client backends wait for AccessExclusive lock on this
relation? Say, a client needs a buffer for some other relation and
that might evict this buffer after we release the lock on the
partition. In StrategyGetBuffer, it is important to either have a pin
on the buffer or the buffer header itself must be locked to avoid
getting picked as victim buffer. Am I missing something?

-- 
With Regards,
Amit Kapila.