From 9c94feae8f98ca996bc7f368f8f1019d478aebc6 Mon Sep 17 00:00:00 2001
From: Ben Darnell <ben@cockroachlabs.com>
Date: Wed, 29 Jul 2015 18:55:51 -0400
Subject: [PATCH 1/2] RFC for bounds generation numbers

---
 docs/RFCS/bounds_generation.md | 44 ++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)
 create mode 100644 docs/RFCS/bounds_generation.md

diff --git a/docs/RFCS/bounds_generation.md b/docs/RFCS/bounds_generation.md
new file mode 100644
index 000000000000..26c6adf2010b
--- /dev/null
+++ b/docs/RFCS/bounds_generation.md
@@ -0,0 +1,44 @@
+- Feature Name: bounds_generation
+- Status: draft
+- Start Date: 2015-07-29
+- RFC PR:
+- Cockroach Issue: #1644
+
+# Summary
+
+Add a **bounds generation number** to all range descriptors, and use
+it to maintain consistency of the store's `rangesByKey` map.
+
+# Motivation
+
+One of the issues in
+[#1644](https://github.com/cockroachdb/cockroach/issues/1644) is that
+a replica may be created in response to a raft message before the
+split that created the range has been processed, leading to conflicts
+in the `Store.rangesByKey` map.
+
+# Detailed design
+
+Add a field `bounds_generation` to `RangeDescriptor`. This value is
+incremented whenever the bounds of the range change. On a split, the
+`bounds_generation` of each post-split range is one plus the pre-split
+`bounds_generation`. On a merge, the `bounds_generation` of the
+post-merge range is one plus the maximum of the two pre-merge ranges'
+values.
+
+In `Store.addRangeInternal`, when we add the range to `rangesByKey`,
+we first test for an overlapping range. If we find one, we compare
+bounds generations: the range with the lower bounds generation has its
+effective bounds reduced to eliminate the conflict.
+
+When this happens, the range whose bounds have been reduced will stop
+receiving KV requests for the affected portion of the keyspace. It
+will, however, continue to receive raft messages, which are routed by
+ID instead of by key. This will allow the replica to catch up and
+process the split transaction that allowed the new range with a higher bounds generation to come into existence (or the replica has been removed and will eventually be garbage-collected).
+
+# Drawbacks
+
+# Alternatives
+
+# Unresolved questions

From 94284229238e3ecec9c9de81b52b8d20adc594c3 Mon Sep 17 00:00:00 2001
From: Ben Darnell <ben@cockroachlabs.com>
Date: Tue, 4 Aug 2015 15:49:31 -0400
Subject: [PATCH 2/2] Reject bounds_generation RFC.

---
 docs/RFCS/bounds_generation.md | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/docs/RFCS/bounds_generation.md b/docs/RFCS/bounds_generation.md
index 26c6adf2010b..2c8253576013 100644
--- a/docs/RFCS/bounds_generation.md
+++ b/docs/RFCS/bounds_generation.md
@@ -1,9 +1,13 @@
 - Feature Name: bounds_generation
-- Status: draft
+- Status: rejected
 - Start Date: 2015-07-29
 - RFC PR:
 - Cockroach Issue: #1644
 
+# Rejection notes
+
+This RFC supplements  #1866, which was rejected.
+
 # Summary
 
 Add a **bounds generation number** to all range descriptors, and use