sqlmigrations: prevent schema change noise upon cluster creation #46832
Conversation
|
This change is |
There was a problem hiding this comment.
Reviewed 1 of 1 files at r2.
Reviewable status:complete! 0 of 0 LGTMs obtained (waiting on @lucy-zhang)
In cockroachdb#46588 a bug was introduced when a retriable error was encountered while using a new transaction for preparing. Prior to that commit, all error were treated as not retriable. This was sort of a bummer. Retriable errors can occur due to read within uncertainty. Before this PR, those retriable errors would make their way to the client. Now we'll handle those retry errors internally underneath `connExecutor.prepare` Fixes cockroachdb#43251 Release note: None
knz
force-pushed
the
20200401-vers
branch
2 times, most recently
from
24934e6 to
75f1439
Compare
|
bors r=lucy-zhang |
|
bors r- |
Canceled |
|
bors r=lucy-zhang |
Build failed (retrying...) |
|
lemme take this out of the queue until its CI finishes bors r- |
Canceled |
The system.comments is now created without write permission to role public. No need to re-do that change on every new cluster. Release note: None Co-authored-by: Lucy Zhang <[email protected]>
|
bors r=lucy-zhang |
|
@knz did you intend for that first commit to be included? |
|
yes - it didn't pass CI otherwise. But that first commit is currently being merged by bors so it will be in the master branch by the time bors gets to this. |
|
I figured that was the reason. It looks like they're queued up in the same batch, though, and I was wondering if bors handles that correctly (I guess I'll find out shortly). |
|
it does (I have used this before). In the occasional case where they don't fit in the same batch, it still all works out because git is clever at reusing commits when the SHAs are identical. |
Build succeeded |
First commit from #46829.
Informs #46757.
The system.comments is now created without write permission to
public. No need to re-do that change on every new cluster.
Release note: None