Advance DB sequence when retrying index build
This patch moves the retrieval of the DB sequence number into the
transaction function. This sequence number is used to determine when the
indexer has completed its work. If the transaction is aborted and
retries, the sequence will advance to the latest committed sequence
observable by the current read version of FDB acquired by the indexer.
This change has significant implications that are not obvious at first
glance. We assert the following:
* A view should, by default, observe a consistent snapshot of the DB as
it existed at some point in time
* The only way to observe a consistent snapshot across multiple
transactions is for the final transaction to process all changes up to
the latest DB sequence observable from the current read version of
that transaction
Without this change, an indexer might only observe a subset of the
outstanding document updates during a retry. This subset does not
necessarily correspond to any historical version of the database, as it
will be missing entries for documents that were updated concurrently
with the previous attempt by the indexer to commit its work. So this is
first and foremost a correctness issue.
Moving the acquisition of the DB sequence inside the indexing
transaction does provides a small latency benefit by avoiding an extra
GRV call on ~idle DBs. Unfortunately, it increases tail latencies for
stale=false view queries on DBs with heavy write loads. If the indexer
cannot complete its work within the 5 second period of validity for its
read version, it will need to add all the additional updates committed
during that interval to the set of documents that it needs to process.
This is the price we pay for having well-defined isolation semantics for
the view. Long-lived read versions would help to alleviate this,
ensuring that the view can always be generated against the version of
the DB available at the beginning of the transaction.
1 file changed
