Re: BUG #18172: High memory usage in tSRF function context
От | Tom Lane |
---|---|
Тема | Re: BUG #18172: High memory usage in tSRF function context |
Дата | |
Msg-id | 1977915.1698516908@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re:BUG #18172: High memory usage in tSRF function context (Sergei Kornilov <sk@zsrv.org>) |
Ответы |
Re:BUG #18172: High memory usage in tSRF function context
|
Список | pgsql-bugs |
Sergei Kornilov <sk@zsrv.org> writes: > Thank you! The patch works for me too. Thanks for testing! I looked at ExecProjectSet a second time and realized that I probably still hadn't thought hard enough, because it's also responsible for doing ResetExprContext(econtext) and that wasn't happening either when looping around after the SRF returns no rows. So if the SRF itself leaks some memory in its CurrentMemoryContext and then returns nothing, we can see bloat in that context. I failed to produce such a behavior with jsonb_array_elements, but after trying some other things I found a test case that still leaked even with the initial patch: create table zed as select repeat('xyzzy', 10000) as f1, repeat('g', 10000) as flags from generate_series(1,100000); select regexp_matches(f1, 'q', flags) from zed; The leak here stems from regexp_matches detoasting its flags argument in the CurrentMemoryContext. A big flags argument is surely not real-world usage, but perhaps there are other cases that are more likely to happen. The fix of course is just to make sure we also do ResetExprContext when looping around. Applied to all branches. regards, tom lane
В списке pgsql-bugs по дате отправления: