Re: OOM in spgist insert

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
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-14 01:01:18
Message-ID: 1785221.1620954078@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

Attachment Content-Type Size
0001-refactor-CHECK_FOR_INTERRUPTS.patch text/x-diff 3.7 KB
0002-fix-query-cancel-in-spgdoinsert.patch text/x-diff 3.5 KB
0003-prevent-infinite-loop-in-spgdoinsert.patch text/x-diff 6.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-05-14 01:03:47 Re: Testing autovacuum wraparound (including failsafe)
Previous Message Greg Nancarrow 2021-05-14 00:37:25 Re: Executor code - found an instance of a WHILE that should just be an IF