Disable recheck_on_update optimization to avoid crashes.

The code added by commit c203d6c causes a crash in at least one case,
where a potentially-optimizable expression index has a storage type
different from the input data type.  A cursory code review turned up
numerous other problems that seem impractical to fix on short notice.

Andres argued for revert of that patch some time ago, and if additional
senior committers had been paying attention, that's likely what would
have happened, but we were not :-(

At this point we can't just revert, at least not in v11, because that would
mean an ABI break for code touching relcache entries.  And we should not
remove the (also buggy) support for the recheck_on_update index reloption,
since it might already be used in some databases in the field.  So this
patch just does the as-little-invasive-as-possible measure of disabling
the feature as though recheck_on_update were forced off for all indexes.
I also removed the related regression tests (which would otherwise fail)
and the user-facing documentation of the reloption.

We should undertake a more thorough code cleanup if the patch can't be
fixed, but not under the extreme time pressure of being already overdue
for 11.1 release.

Per report from Ondřej Bouda and subsequent private discussion among
pgsql-release.

Discussion: https://postgr.es/m/20181106185255.776mstcyehnc63ty@alvherre.pgsql

Author: tglsfdc

doc/src/sgml/ref/create_index.sgml

@@ -356,41 +356,8 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ [ IF NOT EXISTS ] <replaceable class=
    <para>
     The optional <literal>WITH</literal> clause specifies <firstterm>storage
     parameters</firstterm> for the index.  Each index method has its own set of allowed
-    storage parameters.  All indexes accept the following parameter:
-   </para>
-
-   <variablelist>
-   <varlistentry>
-    <term><literal>recheck_on_update</literal></term>
-    <listitem>
-     <para>
-       Specifies whether to recheck a functional index value to see whether
-       we can use a HOT update or not. The default value is on for functional
-       indexes with an total expression cost less than 1000, otherwise off.
-       You might decide to turn this off if you knew that a function used in
-       an index is unlikely to return the same value when one of the input
-       columns is updated and so the recheck is not worth the additional cost
-       of executing the function.
-     </para>
-
-     <para>
-       Functional indexes are used frequently for the case where the function
-       returns a subset of the argument. Examples of this would be accessing
-       part of a string with <literal>SUBSTR()</literal> or accessing a single
-       field in a JSON document using an expression such as
-       <literal>(bookinfo-&gt;&gt;'isbn')</literal>. In this example, the JSON
-       document might be updated frequently, yet it is uncommon for the ISBN
-       field for a book to change so we would keep the parameter set to on
-       for that index. A more frequently changing field might have an index
-       with this parameter turned off, while very frequently changing fields
-       might be better to avoid indexing at all under high load.
-     </para>
-    </listitem>
-   </varlistentry>
-   </variablelist>
-
-   <para>
-     The B-tree, hash, GiST and SP-GiST index methods all accept this parameter:
+    storage parameters.  The B-tree, hash, GiST and SP-GiST index methods all
+    accept this parameter:
    </para>
 
    <variablelist>

doc/src/sgml/release-11.sgml

@@ -1437,19 +1437,6 @@ same commits as above
        </para>
       </listitem>
 
-      <listitem>
-<!--
-2018-03-27 [c203d6cf8] Allow HOT updates for some expression indexes
--->
-
-       <para>
-        Allow heap-only-tuple (<acronym>HOT</acronym>) updates for
-        expression indexes when the values of the expressions are unchanged
-        (Konstantin Knizhnik)
-       </para>
-
-      </listitem>
-
      </itemizedlist>
 
      <sect5>

src/backend/utils/cache/relcache.c

@@ -4755,6 +4755,7 @@ IsProjectionFunctionalIndex(Relation index, IndexInfo *ii)
 {
 	bool		is_projection = false;
 
+#ifdef NOT_USED
 	if (ii->ii_Expressions)
 	{
 		HeapTuple	tuple;
@@ -4800,6 +4801,8 @@ IsProjectionFunctionalIndex(Relation index, IndexInfo *ii)
 		}
 		ReleaseSysCache(tuple);
 	}
+#endif
+
 	return is_projection;
 }
 

src/test/regress/expected/func_index.out

@@ -84,7 +84,7 @@ test: select_into select_distinct select_distinct_on select_implicit select_havi
 # ----------
 # Another group of parallel tests
 # ----------
-test: brin gin gist spgist privileges init_privs security_label collate matview lock replica_identity rowsecurity object_address tablesample groupingsets drop_operator password func_index
+test: brin gin gist spgist privileges init_privs security_label collate matview lock replica_identity rowsecurity object_address tablesample groupingsets drop_operator password
 
 # ----------
 # Another group of parallel tests

src/test/regress/parallel_schedule

@@ -99,7 +99,6 @@ test: portals
 test: arrays
 test: btree_index
 test: hash_index
-test: func_index
 test: update
 test: delete
 test: namespace