Re: [Patch] Optimize dropping of relation buffers using dlist
От | Amit Kapila |
---|---|
Тема | Re: [Patch] Optimize dropping of relation buffers using dlist |
Дата | |
Msg-id | CAA4eK1L5+f_K2Fg+4K8v0GEbS=XJ9BYBYUx02mfk--fpOEzEwA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [Patch] Optimize dropping of relation buffers using dlist (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Список | pgsql-hackers |
On Tue, Dec 22, 2020 at 8:12 AM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > > At Tue, 22 Dec 2020 08:08:10 +0530, Amit Kapila <amit.kapila16@gmail.com> wrote in > > > 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? > > I think exactly like that. If we acquire the bufHdr lock before > releasing the partition lock, that steal doesn't happen but it doesn't > seem good as a locking protocol. > Right, so let's keep the code as it is but I feel it is better to add some comments explaining the rationale behind this code. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: