session, exectutor: Guarantee external consistency by default; Add an explicit begin statement to disable it

[ekexium]

What problem does this PR solve?

Problem Summary:

External consistency is not a widely known concept for many users. So we guarantee it by default, and only allow disabling it by an explicit start transaction with causal consistency only statement.

What is changed and how it works?

What's Changed:

• Hide the tidb_guarantee_external_consistency variable from show variables
• Guarantee external consistency by default
• Add a statement start transaction with causal consistency only to start a transaction that does not require external consistency
• Stop using the ambiguous term "external consistency". Use "linearizability" instead

How it Works:

Related changes

• Add "START TRANSACTION WITH CAUSAL CONSISTENCY ONLY" parser#1162

Check List

Tests

• Integration test (UTF)

Side effects

Release note

• Adds a statement start transaction with causal consistency only to start a transaction that does not require external consistency.
• Rename the sysvar tidb_guarantee_external_consistency to tidb_guarantee_linearizability

[ekexium]

/run-all-tests

[ekexium]

@sticnarf @cfzjywxk PTAL

[sticnarf]

Currently, there are some controversies over how to disable external consistency:

1. The way in this PR is more conservative. The business code programmer fully controls the behavior. It's the safest way because it's so explicit that the programmer must understand external consistency before disabling it.

2. Some others hope to keep the system variables. Because it is quite rare when external consistency is needed, if the business code is known, it will give an easy way to get some performance boost. And external consistency is guaranteed by default, the user disables it at their own risk.

cc @scsldb @jackysp @cfzjywxk @youjiali1995

[youjiali1995]

It's ok to guarantee external consistency by default, but there must be a system variable to control it. We need an easy way to disable it, otherwise, it's difficult to get the best performance in POC or in users' business if they know what external consistency it is.

I'm fine with the syntax and users use it to remove the guarantee by themself, but I think no one will use it...

[sticnarf]

I suggest the async commit related settings changed by the HTTP APIs can be persistent and take effect globally. Then, we needn't set the property again after restarting or adding a new instance.

[ekexium]

/run-all-tests

[sticnarf]

Let's change the ambiguous word "external consistency" in the TiDB repo.

[sticnarf]

@youjiali1995 PTAL

[youjiali1995]

Rest LGTM.

[youjiali1995]

I suggest the async commit related settings changed by the HTTP APIs can be persistent and take effect globally. Then, we needn't set the property again after restarting or adding a new instance.

So we still use the global sysvar?😃 I prefer it to HTTP API.

[sticnarf]

I suggest the async commit related settings changed by the HTTP APIs can be persistent and take effect globally. Then, we needn't set the property again after restarting or adding a new instance.

So we still use the global sysvar?smiley I prefer it to HTTP API.

I wouldn't prefer either. If we don't use sysvar, where do you suggest to put the configurations?

I discussed this with @ekexium about some alternatives like watching a key in the PD's etcd. Personally, I think this solution is simpler if a hidden sysvar is acceptable because we don't need to invent a new mechanism to synchronize configs across TiDB instances.

[youjiali1995]

Personally, I think this solution is simpler if a hidden sysvar is acceptable because we don't need to invent a new mechanism to synchronize configs across TiDB instances.

I mean I agree with it...

[sticnarf]

I mean I agree with it...

sorry I misread the sentence "I prefer it to HTTP API"...

[ekexium]

/run-all-tests

[ekexium]

/run-all-tests

[sticnarf]

LGTM. And please resolve conflicts.

[jackysp]

LGTM

[sticnarf]

LGTM

[sticnarf]

/merge

[ti-srebot]

/run-all-tests