Horton

Re: OOM in spgist insert

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pavel Borisov <pashkin.elfe@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Dilip Kumar <dilipbalaut@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-05-14T12:12:11Z
Lists: pgsql-hackers 
On Thu, May 13, 2021 at 6:20 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> OTOH, the 10-cycles-to-show-progress rule could be
> argued to be an API break.

Not being familiar with this code, I don't really understand why 10
cycles to show progress wouldn't, like 640kB, be enough for anyone.
But as far as back-patching the code goals, I think the question is
not so much whether this restriction could hypothetically break
anything but whether it will actually break anything, which leads to
the question of how many spgist opclasses we think exist outside of
core. I did a Google search and found some evidence that PostGIS might
have such things, and also this:

https://github.com/fake-name/pg-spgist_hamming

There might be other things, but I did not find them.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Commits

  1. Prevent infinite insertion loops in spgdoinsert().

  2. Fix query-cancel handling in spgdoinsert().

  3. Refactor CHECK_FOR_INTERRUPTS() to add flexibility.