Merge remote-tracking branch 'rhaas/chash2014' into rwlock-contention-cleantmp

* rhaas/chash2014: (87 commits)
  Oops.
  Oops.
  Use chash for buftable stuff.
  Fix #includes.
  Rearrange pointers so that the freelist pointers are as far from each other as possible, to reduce contention.
  Code cleanup.
  Reorganize fields to match comments.
  Refactor garbage collection logic into a separate subroutine.
  Set hazard pointers correctly instead of wrong.  Duh.
  De-obfuscate deletion code, maybe.
  Code tightening.
  Add memory barrier in single-node-reclaim case.  Improve comments.
  Get rid of CHashBucketCleanup; CHashBucketScan can do what we need.
  Comment fixes.
  Track GC reclaims skipped in stats.
  Wonky hack to print stats on every backend exit.
  Rewrite statistics system.
  Minor optimization of allocator.
  If we fail to allocate from a non-empty freelist, retry same list.
  Add some missing stats counter bumps.
  ...

3 files changed, 13 insertions, 6 deletions

diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index f4617b67e9..f98e282741 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -1227,8 +1227,7 @@
       <entry><type>bool</type></entry>
       <entry></entry>
       <entry>
-       This represents a not-null constraint.  It is possible to
-       change this column to enable or disable the constraint.
+       This represents a not-null constraint.
       </entry>
      </row>
 
diff --git a/doc/src/sgml/json.sgml b/doc/src/sgml/json.sgml
index 37dd611aeb..8feb2fbf0a 100644
--- a/doc/src/sgml/json.sgml
+++ b/doc/src/sgml/json.sgml
@@ -269,6 +269,12 @@ SELECT '"foo"'::jsonb @> '"foo"'::jsonb;
 -- The array on the right side is contained within the one on the left:
 SELECT '[1, 2, 3]'::jsonb @> '[1, 3]'::jsonb;
 
+-- Order of array elements is not significant, so this is also true:
+SELECT '[1, 2, 3]'::jsonb @> '[3, 1]'::jsonb;
+
+-- Duplicate array elements don't matter either:
+SELECT '[1, 2, 3]'::jsonb @> '[1, 2, 2]'::jsonb;
+
 -- The object with a single pair on the right side is contained
 -- within the object on the left side:
 SELECT '{"product": "PostgreSQL", "version": 9.4, "jsonb":true}'::jsonb @> '{"version":9.4}'::jsonb;
@@ -288,8 +294,10 @@ SELECT '{"foo": {"bar": "baz"}}'::jsonb @> '{"bar": "baz"}'::jsonb;  -- yields f
    The general principle is that the contained object must match the
    containing object as to structure and data contents, possibly after
    discarding some non-matching array elements or object key/value pairs
-   from the containing object.  However, the order of array elements is
-   not significant when doing a containment match.
+   from the containing object.
+   But remember that the order of array elements is not significant when
+   doing a containment match, and duplicate array elements are effectively
+   considered only once.
   </para>
 
   <para>
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f008e937ee..f195495520 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -487,8 +487,8 @@ $$ LANGUAGE plpgsql;
 CREATE FUNCTION extended_sales(p_itemno int)
 RETURNS TABLE(quantity int, total numeric) AS $$
 BEGIN
-    RETURN QUERY SELECT quantity, quantity * price FROM sales
-                 WHERE itemno = p_itemno;
+    RETURN QUERY SELECT s.quantity, s.quantity * s.price FROM sales AS s
+                 WHERE s.itemno = p_itemno;
 END;
 $$ LANGUAGE plpgsql;
 </programlisting>