Github user greghogan commented on a diff in the pull request:
https://github.com/apache/flink/pull/5045#discussion_r152612059
--- Diff: docs/concepts/runtime.md ---
@@ -107,21 +107,20 @@ With hyper-threading, each slot then takes 2 or more
hardware thread contexts.
## State Backends
-The exact data structures in which the key/values indexes are stored
depends on the chosen [state backend](../ops/state/state_backends.html). One
state backend
+The exact data structures in which the key/values indexes are stored
depends on the [state backend](../ops/state/state_backends.html) you choose.
One state backend
stores data in an in-memory hash map, another state backend uses
[RocksDB](http://rocksdb.org) as the key/value store.
-In addition to defining the data structure that holds the state, the state
backends also implement the logic to
-take a point-in-time snapshot of the key/value state and store that
snapshot as part of a checkpoint.
+The state backends also implement the logic to take a point-in-time
snapshot of the key/value state and store that snapshot as part of a checkpoint.
<img src="../fig/checkpoints.svg" alt="checkpoints and snapshots"
class="offset" width="60%" />
{% top %}
## Savepoints
-Programs written in the Data Stream API can resume execution from a
**savepoint**. Savepoints allow both updating your programs and your Flink
cluster without losing any state.
+Programs written in the Data Stream API can resume execution from a
**savepoint**. Savepoints allow both updating your programs and your Flink
cluster without losing any state.
-[Savepoints](../ops/state/savepoints.html) are **manually triggered
checkpoints**, which take a snapshot of the program and write it out to a state
backend. They rely on the regular checkpointing mechanism for this. During
execution programs are periodically snapshotted on the worker nodes and produce
checkpoints. For recovery only the last completed checkpoint is needed and
older checkpoints can be safely discarded as soon as a new one is completed.
+[Savepoints](../ops/state/savepoints.html) are **manually triggered
checkpoints**, which take a snapshot of the program and write it out to a state
backend. They rely on the regular checkpointing mechanism for this. During
execution programs are periodically snapshotted on the worker nodes and produce
checkpoints. The last completed checkpoint is only needed for recovery and you
can safely discard older checkpoints as soon as a new one is completed.
--- End diff --
Should we leave the original but change "can be safely" to "are" or "are by
default"? The paragraph starts discussing savepoints but then switches to
commenting on checkpoints with no distinction about externalized checkpoints.
---
