Re: Out of Memory errors are frustrating as heck!
Вложения
В списке pgsql-performance по дате отправления:
| От | Alvaro Herrera |
|---|---|
| Тема | Re: Out of Memory errors are frustrating as heck! |
| Дата | |
| Msg-id | 20190415173848.GA9165@alvherre.pgsql обсуждение |
| Ответ на | Re: Out of Memory errors are frustrating as heck! (Gunther <raj@gusw.net>) |
| Ответы |
Re: Out of Memory errors are frustrating as heck!
|
| Список | pgsql-performance |
On 2019-Apr-15, Gunther wrote: > #0 AllocSetAlloc (context=0x1168230, size=385) at aset.c:715 > #1 0x000000000084e6cd in palloc (size=385) at mcxt.c:938 > #2 0x000000000061019c in ExecHashJoinGetSavedTuple (file=file@entry=0x8bbc528, hashvalue=hashvalue@entry=0x7fff2e4ca76c, > tupleSlot=0x10856b8, hjstate=0x11688e0) at nodeHashjoin.c:1277 > #3 0x0000000000610c83 in ExecHashJoinNewBatch (hjstate=0x11688e0) at nodeHashjoin.c:1042 Seems that ExecHashJoinGetSavedTuple stores a minimalTuple and sets the shouldFree flag to "true", and then in ExecHashJoinNewBatch, callee ExecFetchSlotMinimalTuple sets shouldFree to false inconditionally when the slot uses minimal tuple ops. Maybe that's correct, but it does sound like a memory leak is not entirely impossible. I wonder if this fixes it, without causing crashes elsewhere. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера