Partially restore comments discussing enum renumbering hazards.

As noted by Tom Lane, commit 813fb0315587d32e3b77af1051a0ef517d187763
was overly optimistic about how safe it is to concurrently change
enumsortorder values under MVCC catalog scan semantics.  Restore
some of the previous text, with hopefully-correct adjustments for
the new state of play.

diff --git a/src/backend/catalog/pg_enum.c b/src/backend/catalog/pg_enum.c
index 88711e985e9fc20bd309a260f629a837111c4444..35899b4a9a727c63839c256496bbd085eb9add46 100644 (file)
--- a/src/backend/catalog/pg_enum.c
+++ b/src/backend/catalog/pg_enum.c
@@ -462,9 +462,22 @@ restart:
  *             Renumber existing enum elements to have sort positions 1..n.
  *
  * We avoid doing this unless absolutely necessary; in most installations
- * it will never happen.  Before we had MVCC catalog scans, this function
- * posed various concurrency hazards.  It no longer does, but it's still
- * extra work, so we don't do it unless it's needed.
+ * it will never happen.  The reason is that updating existing pg_enum
+ * entries creates hazards for other backends that are concurrently reading
+ * pg_enum.     Although system catalog scans now use MVCC semantics, the
+ * syscache machinery might read different pg_enum entries under different
+ * snapshots, so some other backend might get confused about the proper
+ * ordering if a concurrent renumbering occurs.
+ *
+ * We therefore make the following choices:
+ *
+ * 1. Any code that is interested in the enumsortorder values MUST read
+ * all the relevant pg_enum entries with a single MVCC snapshot, or else
+ * acquire lock on the enum type to prevent concurrent execution of
+ * AddEnumLabel().
+ *
+ * 2. Code that is not examining enumsortorder can use a syscache
+ * (for example, enum_in and enum_out do so).
  */
 static void
 RenumberEnumType(Relation pg_enum, HeapTuple *existing, int nelems)