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

From Tom Lane
Subject Re: OOM in spgist insert
Date
Msg-id 1787101.1620956647@sss.pgh.pa.us
Whole thread Raw
In response to Re: OOM in spgist insert  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> Anyway, here is a patch set teased apart into committable bites,
> and with your other points addressed.

Oh, maybe some docs would be a good thing too ...

            regards, tom lane

diff --git a/doc/src/sgml/spgist.sgml b/doc/src/sgml/spgist.sgml
index cfb2b3c836..18f1f3cdbd 100644
--- a/doc/src/sgml/spgist.sgml
+++ b/doc/src/sgml/spgist.sgml
@@ -978,6 +978,18 @@ LANGUAGE C STRICT;
    fails to do that, the <acronym>SP-GiST</acronym> core resorts to
    extraordinary measures described in <xref linkend="spgist-all-the-same"/>.
   </para>
+
+  <para>
+   When <structfield>longValuesOK</structfield> is true, it is expected
+   that successive levels of the <acronym>SP-GiST</acronym> tree will
+   absorb more and more information into the prefixes and node labels of
+   the inner tuples, making the required leaf datum smaller and smaller,
+   so that eventually it will fit on a page.
+   To prevent bugs in operator classes from causing infinite insertion
+   loops, the <acronym>SP-GiST</acronym> core will raise an error if the
+   leaf datum does not become any smaller within ten cycles
+   of <function>choose</function> method calls.
+  </para>
  </sect2>
 
  <sect2 id="spgist-null-labels">

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: compute_query_id and pg_stat_statements
Next
From: Tom Lane
Date:
Subject: Re: compute_query_id and pg_stat_statements