From: | Tomas Vondra <tomas(at)vondra(dot)me> |
---|---|
To: | Vinod Sridharan <vsridh90(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Parallel CREATE INDEX for GIN indexes |
Date: | 2025-04-21 09:49:06 |
Message-ID: | a8775477-7396-43b4-99dd-aa0cf9204cd3@vondra.me |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Frédéric Yhuel | 2025-04-21 11:01:08 | Re: [BUG] temporary file usage report with extended protocol and unnamed portals |
Previous Message | Rahila Syed | 2025-04-21 09:47:41 | Re: Memory context can be its own parent and child in replication command |