Design doc updates #9646
Design doc updates #9646
Conversation
|
|
||
| - `\0\0meta1` Range metadata for location of `\0\0meta2`. | ||
| - `\0\0meta1<key1>` Range metadata for location of `\0\0meta2<key1>`. | ||
| - `\x02<key1>`: Range metadata for range ending `\x03<key1>`. |
There was a problem hiding this comment.
I think it is worth mentioning this is a meta1 key. Ditto for the \x03 and \x04 prefix below.
| - `\x03<keyN>`: Range metadata for range ending `<keyN>`. | ||
| - `\x04{desc,node,range,store}-idegen`: ID generation oracles for various component types. | ||
| - `\x04status-node-<varint encoded Store ID>`: Store runtime metadata. | ||
| - `\x04tsd<...>`: Time-series data. | ||
| - `<key0>`: `<value0>` The first user data key.** |
There was a problem hiding this comment.
user data key is mildly confusing. Perhaps table data key.
| @@ -209,27 +209,27 @@ on a node is at a timestamp < next HLC time. | |||
|
|
|||
| Transactions are executed in two phases: | |||
|
|
|||
| 1. Start the transaction by writing a new entry to the system | |||
| transaction table (keys prefixed by *\0tx*) with state “PENDING”. In | |||
| 1. Start the transaction by selecting a range which is likely to be | |||
There was a problem hiding this comment.
s/is likely to be heavily involved in the transaction/involved in the first write of the transaction/
There was a problem hiding this comment.
Why? Isn't this what we just discussed as being the more-likely-to-rot variant?
There was a problem hiding this comment.
Yeah, agree that this is too specific.
| @@ -267,7 +267,7 @@ encounter data that necessitate conflict resolution | |||
|
|
|||
| When a transaction restarts, it changes its priority and/or moves its | |||
| timestamp forward depending on data tied to the conflict, and | |||
| begins anew reusing the same tx id. The prior run of the transaction might | |||
| begins anew reusing the same txn id. The prior run of the transaction might | |||
| have written some write intents, which need to be deleted before the | |||
| transaction commits, so as to not be included as part of the transaction. | |||
There was a problem hiding this comment.
Not correct, epochs take care of this.
There was a problem hiding this comment.
The whole section from here down is bogus.
| @@ -267,7 +267,7 @@ encounter data that necessitate conflict resolution | |||
|
|
|||
| When a transaction restarts, it changes its priority and/or moves its | |||
| timestamp forward depending on data tied to the conflict, and | |||
| begins anew reusing the same tx id. The prior run of the transaction might | |||
| begins anew reusing the same txn id. The prior run of the transaction might | |||
| have written some write intents, which need to be deleted before the | |||
| transaction commits, so as to not be included as part of the transaction. | |||
There was a problem hiding this comment.
The whole section from here down is bogus.
| clean up after itself. The next attempt (if applicable) then runs as a | ||
| new transaction with **a new tx id**. | ||
| record, finds that it has been aborted. In this case, the transaction | ||
| can not reuse its intents; it returns control to the client before |
There was a problem hiding this comment.
It never really reuses intents. The intents' primary role is that of preventing starvation by forcing conflicts.
| dangling intents as they encounter them) but will make an effort to | ||
| clean up after itself. The next attempt (if applicable) then runs as a | ||
| new transaction with **a new tx id**. | ||
| record, finds that it has been aborted. In this case, the transaction |
There was a problem hiding this comment.
s/upon/usually upon/ (because abort span, etc)
| - `\x03<keyN>`: Range metadata for range ending `<keyN>`. This a "meta2" key. | ||
| - `\x04{desc,node,range,store}-idegen`: ID generation oracles for various component types. | ||
| - `\x04status-node-<varint encoded Store ID>`: Store runtime metadata. | ||
| - `\x04tsd<key>`: Time-series data key. |
There was a problem hiding this comment.
Where did zones go? Are they in one of the magic tables?
|
@tschottdorf can the lies which I re-wrapped be addressed subsequently? Zones are now in a SQL table. |
|
Sure. |
This change is