Re: Improper usage of MemoryContext in nodeSubplan.c for buildSubPlanHash() function. This maybe causes allocate memory failed.
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Improper usage of MemoryContext in nodeSubplan.c for buildSubPlanHash() function. This maybe causes allocate memory failed. |
| Дата | |
| Msg-id | 22050.1280287098@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Improper usage of MemoryContext in nodeSubplan.c for buildSubPlanHash() function. This maybe causes allocate memory failed. ("Tao Ma" <feng_eden@163.com>) |
| Ответы |
Re: Improper usage of MemoryContext in nodeSubplan.c for buildSubPlanHash() function. This maybe causes allocate memory failed.
|
| Список | pgsql-hackers |
"Tao Ma" <feng_eden@163.com> writes:
> This is a potential memory error in nodeSubplan.c or execGrouping.c
> Using select '1'::TEXT IN ((SELECT '1'::NAME) UNION ALL SELECT '1'::NAME);
> to reproduce this bug.
> ...
> To fix this problem, we can use another memory context to passin
> BuildTupleHashTable() as the hashtable's tempcxt, or use other memory
> context as hash table's tempcxt or other ways.
Yeah, I think you're right --- we can't get away with reusing the
innerecontext's per-tuple context for the hashtable temp contexts.
The best solution is probably to make an additional context that
does nothing but act as the hashtable temp context.
This bug's been there a long time :-(. Surprising that no one found it
before. It would be mostly masked in a non-assert build, but not
entirely, I think.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера