From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: OOM in spgist insert |
Date: | 2021-05-13 22:49:33 |
Message-ID: | 20210513224933.GA20201@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Borisov | 2021-05-13 22:49:49 | Re: OOM in spgist insert |
Previous Message | Tom Lane | 2021-05-13 22:45:14 | Re: Always bump PG_CONTROL_VERSION? |