Re: OOM in spgist insert

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: OOM in spgist insert
Дата
Msg-id 20210513224933.GA20201@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: OOM in spgist insert  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: OOM in spgist insert  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 2021-May-13, Tom Lane wrote:

> What do people think about back-patching this?  In existing branches,
> we've defined it to be an opclass bug if it fails to shorten the leaf
> datum enough.  But not having any defenses against that seems like
> not a great idea.  OTOH, the 10-cycles-to-show-progress rule could be
> argued to be an API break.

I think if the alternative is to throw an error, we can afford to retry
quite a few more times than 10 in order not have that called an API
break.  Say, retry (MAXIMUM_ALIGNOF << 3) times or so (if you want to
parameterize on maxalign).  It's not like this is going to be a
performance drag where not needed .. but I think leaving back-branches
unfixed is not great.

I did run Dilip's test case as well as your new regression test, and
both work as intended with your new code (and both OOM-crash the
original code).

-- 
Álvaro Herrera       Valdivia, Chile



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Always bump PG_CONTROL_VERSION?
Следующее
От: Pavel Borisov
Дата:
Сообщение: Re: OOM in spgist insert