RE: [Patch] Optimize dropping of relation buffers using dlist
От | tsunakawa.takay@fujitsu.com |
---|---|
Тема | RE: [Patch] Optimize dropping of relation buffers using dlist |
Дата | |
Msg-id | TYAPR01MB2990366A476C3B35BAA8A4EEFEDF0@TYAPR01MB2990.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: [Patch] Optimize dropping of relation buffers using dlist (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: [Patch] Optimize dropping of relation buffers using dlist
Re: [Patch] Optimize dropping of relation buffers using dlist |
Список | pgsql-hackers |
From: Amit Kapila <amit.kapila16@gmail.com> > 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? Ouch, right. (The year-end business must be making me crazy...) So, there are two choices here: 1) The current patch. 2) Acquire the buffer header spinlock before releasing the buffer mapping lwlock, and eliminate the buffer tag comparisonas follows: BufTableLookup(); LockBufHdr(); LWLockRelease(); InvalidateBuffer(); I think both are okay. If I must choose either, I kind of prefer 1), because LWLockRelease() could take longer time to wakeup other processes waiting on the lwlock, which is not very good to do while holding a spinlock. Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: