Cope with smaller-than-normal BLCKSZ setting in SPGiST indexes on text.

The original coding failed miserably for BLCKSZ of 4K or less, as reported
by Josh Kupershmidt.  With the present design for text indexes, a given
inner tuple could have up to 256 labels (requiring either 3K or 4K bytes
depending on MAXALIGN), which means that we can't positively guarantee no
failures for smaller blocksizes.  But we can at least make it behave sanely
so long as there are few enough labels to fit on a page.  Considering that
btree is also more prone to "index tuple too large" failures when BLCKSZ is
small, it's not clear that we should expend more work than this on this
case.

src/backend/access/spgist/spgtextproc.c

@@ -29,10 +29,16 @@
  * of size BLCKSZ.	Rather than assuming we know the exact amount of overhead
  * imposed by page headers, tuple headers, etc, we leave 100 bytes for that
  * (the actual overhead should be no more than 56 bytes at this writing, so
- * there is slop in this number).  The upshot is that the maximum safe prefix
- * length is this:
+ * there is slop in this number).  So we can safely create prefixes up to
+ * BLCKSZ - 256 * 16 - 100 bytes long.  Unfortunately, because 256 * 16 is
+ * already 4K, there is no safe prefix length when BLCKSZ is less than 8K;
+ * it is always possible to get "SPGiST inner tuple size exceeds maximum"
+ * if there are too many distinct next-byte values at a given place in the
+ * tree.  Since use of nonstandard block sizes appears to be negligible in
+ * the field, we just live with that fact for now, choosing a max prefix
+ * size of 32 bytes when BLCKSZ is configured smaller than default.
  */
-#define SPGIST_MAX_PREFIX_LENGTH	(BLCKSZ - 256 * 16 - 100)
+#define SPGIST_MAX_PREFIX_LENGTH	Max((int) (BLCKSZ - 256 * 16 - 100), 32)
 
 /* Struct for sorting values in picksplit */
 typedef struct spgNodePtr