From: | Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: OOM in spgist insert |
Date: | 2021-05-12 08:39:04 |
Message-ID: | CALT9ZEHj7nrBQwxwi_6xsd9t87qYDb6uRBA_g51N5+CvW2yriw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
ср, 12 мая 2021 г. в 12:36, Dilip Kumar <dilipbalaut(at)gmail(dot)com>:
> On Wed, 12 May 2021 at 1:43 PM, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>
> wrote:
>
>> ср, 12 мая 2021 г. в 11:09, Dilip Kumar <dilipbalaut(at)gmail(dot)com>:
>>
>>> While testing something on spgist I found that at certain point while
>>> inserting in spgist it is going for doPickSplit, but even after split
>>> is is not able to find a place to insert a tuple and it keeping going
>>> in that loop infinitely it seems and finally error out with OOM
>>> because in this loop we are continuously allocating memory for the
>>> tuple in temp context but since we are never coming out of the loop it
>>> is erroring out with OOM.
>>>
>>> My first idea is that this is the case when index tuple doesn't fit into
>> one index page. As INCLUDED columns are added as is the tuple can not be
>> made shorter by prefix-stripping. Seems we should check every index tuple
>> length to fit the page before its insertion.
>>
>
> Thanks for looking into this.
>
> Will see the code little bit later.
>>
>
> Ok
>
PFA v1 patch. Does this help?
--
Best regards,
Pavel Borisov
Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Check-inserted-SpGist-tuple-fit-the-index-page-in.patch | application/octet-stream | 1.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Borisov | 2021-05-12 08:51:04 | Re: OOM in spgist insert |
Previous Message | Dilip Kumar | 2021-05-12 08:36:47 | Re: OOM in spgist insert |