Stopgap solution for problem reported by Alexey Beschiokov: after

doing heap_insert or heap_update, wipe out any extracted fields in
the TupleTableSlot containing the tuple, because they might not be valid
anymore if tuptoaster.c changed the tuple.  Safe because slot must be
in the materialized state, but mighty ugly --- find a better answer!

src/backend/executor/execMain.c

@@ -26,7 +26,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/executor/execMain.c,v 1.256.2.1 2005/11/14 17:43:12 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/executor/execMain.c,v 1.256.2.2 2005/11/19 20:58:42 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -1445,6 +1445,16 @@ ExecInsert(TupleTableSlot *slot,
 	estate->es_lastoid = newId;
 	setLastTid(&(tuple->t_self));
 
+	/*
+	 * KLUGE SOLUTION for bug found post 8.1 release: if the tuple toaster
+	 * fired on the tuple then it changed the physical tuple inside the
+	 * tuple slot, leaving any extracted information invalid.  Mark the
+	 * extracted state invalid just in case.  Need to fix things so that
+	 * the toaster gets to run against the tuple before we materialize it,
+	 * but that's way too invasive for a stable branch.
+	 */
+	slot->tts_nvalid = 0;
+
 	/*
 	 * insert index entries for tuple
 	 */
@@ -1699,6 +1709,16 @@ lreplace:;
 	IncrReplaced();
 	(estate->es_processed)++;
 
+	/*
+	 * KLUGE SOLUTION for bug found post 8.1 release: if the tuple toaster
+	 * fired on the tuple then it changed the physical tuple inside the
+	 * tuple slot, leaving any extracted information invalid.  Mark the
+	 * extracted state invalid just in case.  Need to fix things so that
+	 * the toaster gets to run against the tuple before we materialize it,
+	 * but that's way too invasive for a stable branch.
+	 */
+	slot->tts_nvalid = 0;
+
 	/*
 	 * Note: instead of having to update the old index tuples associated with
 	 * the heap tuple, all we do is form and insert new index tuples. This is