Add summarization comment about visibility functions.

Add URL about the Halloween problem.

src/backend/utils/time/tqual.c

@@ -26,12 +26,31 @@
  * subtransactions of our own main transaction and so there can't be any
  * race condition.
  *
+ * Summary of visibility functions:
+ *
+ *   HeapTupleSatisfiesMVCC()
+ *        visible to supplied snapshot, excludes current command
+ *   HeapTupleSatisfiesNow()
+ *        visible to instant snapshot, excludes current command
+ *   HeapTupleSatisfiesUpdate()
+ *        like HeapTupleSatisfiesNow(), but with user-supplied command
+ *        counter and more complex result
+ *   HeapTupleSatisfiesSelf()
+ *        visible to instant snapshot and current command
+ *   HeapTupleSatisfiesDirty()
+ *        like HeapTupleSatisfiesSelf(), but includes open transactions
+ *   HeapTupleSatisfiesVacuum()
+ *        visible to any running transaction, used by VACUUM
+ *   HeapTupleSatisfiesToast()
+ *        visible unless part of interrupted vacuum, used for TOAST
+ *   HeapTupleSatisfiesAny()
+ *        all tuples are visible
  *
  * Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
  * Portions Copyright (c) 1994, Regents of the University of California
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/utils/time/tqual.c,v 1.111 2009/01/01 17:23:53 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/utils/time/tqual.c,v 1.112 2009/03/09 13:08:05 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -277,7 +296,7 @@ HeapTupleSatisfiesSelf(HeapTupleHeader tuple, Snapshot snapshot, Buffer buffer)
  *
  * Note we do _not_ include changes made by the current command.  This
  * solves the "Halloween problem" wherein an UPDATE might try to re-update
- * its own output tuples.
+ * its own output tuples, http://en.wikipedia.org/wiki/Halloween_Problem.
  *
  * Note:
  *		Assumes heap tuple is valid.