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
