Here’s something I wanted to get some opinions on: as you know, crdb automatically retries statements when it can, in response to retryable errors. The interaction between these retries and the behaviour of non-transactional statements has not been thought out. For example,
PREPARE and some
SET statements have effect that outlive the transaction. This can lead to serious consequences:
SET SEARCH_PATH=foo BEGIN INSERT INTO test.t FROM t; SET SEARCH_PATH=bar; SELECT * FROM test.t; COMMIT
Assume the SELECT gets a retryable error. On the first attempt, the txn copies data from
foo.t. On subsequent attempts, it will copy data from
Less catastrophic, but more likely,
PREPAREing in a txn will fail on anything but the first attempt because the prepared statement will already exist.
The reasoning behind our automatic retries is that, if you discard the intents laid down by a txn, there’s no other side effects to take into consideration. The problem exists with user-directed retries too, except that, as opposed to automatic retries, in this case the client at least theoretically can restore state / avoid re-executing some statements.
What do y’all think we should do about this? The only option I see is to make all statements transactional: apply all side-effects only when a txn commits.