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
|
Список | 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 по дате отправления: