Re: PG18 GIN parallel index build crash - invalid memory alloc request size

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: PG18 GIN parallel index build crash - invalid memory alloc request size
Дата
Msg-id bfde94f6-ade6-4129-846b-8724c1630050@vondra.me
обсуждение исходный текст
Ответ на Re: PG18 GIN parallel index build crash - invalid memory alloc request size  (Tomas Vondra <tomas@vondra.me>)
Список 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




В списке pgsql-hackers по дате отправления: