Re: Parallel CREATE INDEX for GIN indexes - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: Parallel CREATE INDEX for GIN indexes
Date
Msg-id a8775477-7396-43b4-99dd-aa0cf9204cd3@vondra.me
Whole thread Raw
In response to Re: Parallel CREATE INDEX for GIN indexes  (Vinod Sridharan <vsridh90@gmail.com>)
List 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 by date:

Previous
From: Rahila Syed
Date:
Subject: Re: Memory context can be its own parent and child in replication command
Next
From: Frédéric Yhuel
Date:
Subject: Re: [BUG] temporary file usage report with extended protocol and unnamed portals