Add an ability to reset custom setting to default and remove it from table's metadata.
This will allow to rollback the change without knowing the system/config's default.
Signed-off-by: Aleksei Semiglazov <asemiglazov@cloudflare.com>
TODO (suggested by Nikolai)
1. Build query plan fro current query (inside storage::read) up to WithMergableState
2. Check, that plan is simple enough: Aggregating - Expression - Filter - ReadFromStorage (or simplier)
3. Check, that filter is the same as filter in projection, and also expression calculates the same aggregation keys as in projection
4. Return WithMergableState if projection applies
3 will be easier to do with ActionsDAG, cause it sees all functions, and dependencies are direct (but it is possible with ExpressionActions also)
Also need to figure out how prewhere works for projections, and
row_filter_policies.
wip
This PR fixes a lock issue that happens while executing
`ALTER LIVE VIEW` query with the `REFRESH` command that
results in a exception. The problem is that lock is currently
being acquired in `InterpreterALterQuery.cpp`
in the `InterpreterAlterQuery::execute()` method and lock
is again being reacquired in `StorageLiveView.cpp` in the
` StorageLiveView::refresh` method. This removes that extra
lock.
Before fix:
```sql
--create table
CREATE TABLE test0 (
c0 UInt64
) ENGINE = MergeTree() PARTITION BY c0 ORDER BY c0;
-- enable experimental_live_view
:) SET allow_experimental_live_view=1
-- create live view;
:) CREATE LIVE VIEW live1 AS SELECT * FROM table0;
-- alter live view results in exception
:) ALTER LIVE VIEW live1 REFRESH;
...
...
Received exception from server (version 20.8.1):
Code: 49. DB::Exception: Received from localhost:9000. DB::Exception: RWLockImpl::getLock(): RWLock is already locked in exclusive mode.
```
After fix:
```sql
:) ALTER LIVE VIEW live1 REFRESH;
ALTER LIVE VIEW live1
REFRESH
Ok.
0 rows in set. Elapsed: 0.016 sec.
```
In this version of the databaseReplicated sequential persistent zk nodes
are used to order DDL queries. Db replicated ddl queries are executed
in the backgrould pool no matter whether it's proposed by the same
replica or not.
