sql: use a CockroachDB-specific error code for schg errs upon COMMIT #37791
This patch changes the error reported upon schema change failures
Previously, this situation used the extant PostgreSQL error code
Using a separate error code ensures the situation is more noticeable
After this patch:
(in this specific example, the ALTER failed but the INSERT was
Some context for the reader not familiar with this situation (I had to
At that point:
In effect, the transaction is both committed and aborted at the same
Release note (sql change): CockroachDB now reports a dedicated SQL
5 times, most recently
May 24, 2019
andreimatei left a comment
I've told you my opinion on this - I think the "statement completion unknown" code was better. The situation addressed here (a fairly esoteric edge case of having both DDL and non-DDL statements in a txn) doesn't seem worth-while to me for introducing a 2nd (server-side) code that means "your transaction might have been committed even though you're getting an error". Having one such code is probably complicated enough for a user. Particularly since it's us introducing this code, not Postgres, so it seems unreasonable to expect anybody to know about it. If we were ruling the world yet and control some drivers, etc, I'd probably think differently :)
andreimatei left a comment
Btw, I don't actually claim to know when Postgres uses the "statement completion unknown" code exactly. I believe I've tried to look into it in the past without much success. I think maybe Postgres doesn't use it at all and perhaps it's just for load-balancers.
lucy-zhang left a comment
The code and tests look fine. I agree that this error is an entirely different type of error from our other use of
@knz I think you know this, but this is context for anyone else reading: The reason why DDL statements behave this way is that for some schema changes, including adding/dropping columns and indexes, most of the work is done asynchronously in a sequence of transactions after the user transaction has committed, even though the gateway node doesn't return results to the client until all the schema changes are finished. When one of these schema changes is "aborted" due to an error, what actually happens is that there are more transactions which undo the effects of the previous ones. (This will not, however, undo the effects of schema changes that were completed entirely in the user transaction, like
Thank you. I am going to go ahead and merge this (as approved by Lucy).
Andrei you wrote that a description of the new situation would be your transaction might have been committed even though you're getting an error. That is simply not true. The transaction has certainly committed and the client is getting an error. So some effects of the transactions were not aborted. This is a qualitatively different situation from the other case where the commit status is truly unknown.