Re: OOM in spgist insert - Mailing list pgsql-hackers

From Pavel Borisov
Subject Re: OOM in spgist insert
Date
Msg-id CALT9ZEEuDGc6O276nWSvEtQKbfzZZRijCu175PF7=RsBq9Xm1g@mail.gmail.com
Whole thread Raw
In response to Re: OOM in spgist insert  (Pavel Borisov <pashkin.elfe@gmail.com>)
Responses Re: OOM in spgist insert
List pgsql-hackers


ср, 12 мая 2021 г. в 12:39, Pavel Borisov <pashkin.elfe@gmail.com>:
ср, 12 мая 2021 г. в 12:36, Dilip Kumar <dilipbalaut@gmail.com>:
On Wed, 12 May 2021 at 1:43 PM, Pavel Borisov <pashkin.elfe@gmail.com> wrote:
ср, 12 мая 2021 г. в 11:09, Dilip Kumar <dilipbalaut@gmail.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?
I've made a mistake in attributes count in v1. PFA v2 


--
Best regards,
Pavel Borisov

Postgres Professional: http://postgrespro.com
Attachment

pgsql-hackers by date:

Previous
From: Pavel Borisov
Date:
Subject: Re: OOM in spgist insert
Next
From: Pavel Stehule
Date:
Subject: Re: compute_query_id and pg_stat_statements