Re: Parallel CREATE INDEX for GIN indexes
От | Tomas Vondra |
---|---|
Тема | Re: Parallel CREATE INDEX for GIN indexes |
Дата | |
Msg-id | a8775477-7396-43b4-99dd-aa0cf9204cd3@vondra.me обсуждение исходный текст |
Ответ на | Re: Parallel CREATE INDEX for GIN indexes (Vinod Sridharan <vsridh90@gmail.com>) |
Список | pgsql-hackers |
On 4/18/25 03:03, Vinod Sridharan wrote: > Hello, > As part of testing this change I believe I found a scenario where the > parallel build seems to trigger OOMs for larger indexes. Specifically, > the calls for ginEntryInsert seem to leak memory into > TopTransactionContext and OOM/crash the outer process. > For serial build, the calls for ginEntryInsert tend to happen in a > temporary memory context that gets reset at the end of the > ginBuildCallback. > For inserts, the call has a custom memory context and gets reset at > the end of the insert. > For parallel build, during the merge phase, the MemoryContext isn't > swapped - and so this happens on the TopTransactionContext, and ends > up growing (especially for larger indexes). > > I believe at the very least these should happen inside the tmpCtx > found in the GinBuildState and reset periodically. > > In the attached patch, I've tried to do this, and I'm able to build > the index without OOMing, and only consuming maintenance_work_mem > through the merge process. > > Would appreciate your thoughts on this (and whether there's other approaches to > resolve this too). > Thanks for the report. I didn't have time to look at this in detail yet, but the fix looks roughly correct. I've added this to the list of open items for PG18. regards -- Tomas Vondra
В списке pgsql-hackers по дате отправления: