Re: BufferAlloc: don't take two simultaneous locks
От | Robert Haas |
---|---|
Тема | Re: BufferAlloc: don't take two simultaneous locks |
Дата | |
Msg-id | CA+TgmobXcqsPhej_opBkCYO7aSh-TheesBVRF2P1k15OCkzkzQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BufferAlloc: don't take two simultaneous locks (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: BufferAlloc: don't take two simultaneous locks
Re: BufferAlloc: don't take two simultaneous locks |
Список | pgsql-hackers |
On Fri, Apr 15, 2022 at 4:29 AM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > The patch removes buftable entry frist then either inserted again or > returned to freelist. I don't understand how it can be in both > buftable and freelist.. What kind of trouble do you have in mind for > example? I'm not sure. I'm just thinking about potential dangers. I was more worried about it ending up in neither place. > So, does this get progressed if someone (maybe Yura?) runs a > benchmarking with this method? I think we're talking about theoretical concerns about safety here, and you can't resolve that by benchmarking. Tom or others may have a different view, but IMHO the issue with this patch isn't that there are no performance benefits, but that the patch needs to be fully safe. He and I may disagree on how likely it is that it can be made safe, but it can be a million times faster and if it's not safe it's still dead. Something clearly needs to be done to plug the specific problem that I mentioned earlier, somehow making it so we never need to grow the hash table at runtime. If anyone can think of other such hazards those also need to be fixed. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: