From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: OOM in spgist insert |
Date: | 2021-05-14 05:27:34 |
Message-ID: | CAFiTN-t8Ms6K-e5vk3iPm+z8HV6UWgzmxDRzDhfJZxfWoOYe_g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, May 14, 2021 at 6:31 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-05-14 05:30:14 | Re: subscriptioncheck failure |
Previous Message | Kyotaro Horiguchi | 2021-05-14 05:24:30 | Re: Race condition in recovery? |