Re: OOM in spgist insert
От | Dilip Kumar |
---|---|
Тема | Re: OOM in spgist insert |
Дата | |
Msg-id | CAFiTN-t8Ms6K-e5vk3iPm+z8HV6UWgzmxDRzDhfJZxfWoOYe_g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: OOM in spgist insert (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: OOM in spgist insert
|
Список | pgsql-hackers |
On Fri, May 14, 2021 at 6:31 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > > 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. > > Hm. Index bloat is not something to totally ignore, though, so I'm > not sure what the best cutoff is. > > Anyway, here is a patch set teased apart into committable bites, > and with your other points addressed. I have tested with my original issue and this patch is fixing the issue. Thanks! -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: