At the moment, not only is there no deferment and the world has not collapsed
I'd also wait a bit until we've seen 19.2 perform in the wild. Down the line, to truly enable global transactions, we're thinking about introducing read locks, which, when held, could significantly cheapen the refresh (though a latency cost stays). But even in 20.1, it generally seems appropriate to refresh early by default and opt out of that behavior through SELECT FOR UPDATE, which should be able to address the pathological cases we're worried about here.Come to think of it though, I wonder what the efficient way to use SELECT FOR UPDATE will be. For example, if the transaction carries out three CPuts each of which hits a different table, and each of them will catch a WriteTooOld, would we recommend to our customers something like this:SELECT v FROM c WHERE id = 1 FOR UPDATE UNION ALL SELECT v FROM b WHERE id = 2 FOR UPDATE UNION ALL SELECT v FROM a WHERE id = 3 FOR UPDATE;
(I assume there's a benefit to keeping this all in the same transaction, namely avoiding uncertainty restarts or the like). It is somehow awkward that SFU forces us to actually return rows to the client, it would be nicer to think of it as a blind write, which of course should never be able to get WriteTooOld.
#38668 didn't go in until 19.2, which no one but us is running, so this could just be a blind spot in our testing. I'd like to see evidence that the world continues not to collapse after the release of 19.2 before committing to this path.
(I haven't caught up on the SFU RFC, so apologies if I'm beating a dead horse. I trust that you and Raphael will think this all through and have answers in the RFC).
I don't know of a SFU RFC and even less that I was involved. When
is this due?
(My hands are a bit full with savepoints at this moment.)
In the context of savepoints I am currently merely drawing an inventory of the various kinds of errors and what txn state can be restored during a savepoint rollback (partial txn rollback).
There will be "interesting" questions when SFU work will start _after_ savepoints are a thing, but I hope I can keep that out of scope at least for one more month.
-- Raphael 'kena' Poss
You received this message because you are subscribed to the Google Groups "KV" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kv+unsu...@cockroachlabs.com.
To view this discussion on the web visit https://groups.google.com/a/cockroachlabs.com/d/msgid/kv/CAHkUbgNn%3D%2BrgT9_JP7up2U3KZ%2Bc45fvJYVVmisb6QAzByPL2Zw%40mail.gmail.com.
Andrei, if you remove WriteTooOld but continue laying down an intent before the restart to avoid starvation, what is your plan for doing that? It seems unsatisfying to return WriteTooOldError but to lay down the intent at the same time because then we'll have to distinguish between errors that do and those that don't throughout the Replica code.
Similar to points I've made earlier and the footnote in your email, communicating transaction state through errors seems awkward there.When you take a step back, the WriteTooOld flag really is "you will fail the refresh".
A ReadWithinUncertaintyIntervalError communicates the same. It seems more natural to remove WriteTooOldError and ReadWithinUncertaintyIntervalError instead of removing the WriteTooOld flag (which we'll rename instead). We want the gateway to run its transaction, and with each response it can decide what to do (before showing the result to the client). Your suggestion is "keep running until we learn that we'll fail a refresh", which it can easily implement by looking at the read and write timestamps as well as the flag; deciding instead to run the transaction all the way through is also simple to implement. (The code in EndTransaction goes away anyway). To add a devil's advocate argument, we're returning one batch of results the client won't use. (This last argument will fall apart to some extent as we get into optimistic reads and/or writes; it'll necessarily be more common to do extra work in the unhappy case). One other argument for keeping the errors is that they can be counted and shown to clients, to maybe explain their transaction to them. (Though this is better done by keeping a log at the gateway that interprets the state changes.)