Re: PG18 GIN parallel index build crash - invalid memory alloc request size
Tomas Vondra <tomas@vondra.me>
From: Tomas Vondra <tomas@vondra.me>
To: Gregory Smith <gregsmithpgsql@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-11-04T19:27:52Z
Lists: pgsql-hackers
On 10/29/25 19:47, Tomas Vondra wrote: > ... > Unsurprisingly, there were a couple more palloc/repalloc calls (in > ginPostingListDecodeAllSegments) that could fail with long TID lists > produced when merging worker data. The attached v4 fixes this. > > However, I see this as a sign that allowing huge allocations is not the > right way to fix this. The GIN code generally assumes, and I don't think > reworking this in a bugfix seems a bit too invasive. And I'm not really > certain this is the last place that could hit this. > > Another argument against 0001 is using more memory does not really help > anything. It's not any faster or simpler. It's more like "let's use the > memory we have" rather than "let's use the memory we need". > > So I'm planning to get rid of 0001, and fix that by 0002 or 0002+0003. > That seems like a better and (unexpectedly) less invasive fix. > I ended up pushing 0002, for the reasons explained above. This fixes the allocation issue simply by not needing too much memory. The 0003 is more of an optimization, so I pushed that only to master. regards -- Tomas Vondra
Commits
-
Trim TIDs during parallel GIN builds more eagerly
- 1213cb475391 19 (unreleased) landed
-
Limit the size of TID lists during parallel GIN build
- c98dffcb7c70 19 (unreleased) landed
- a26b753a0894 18.1 landed