-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-37098][SQL] Alter table properties should invalidate cache #34365
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
yaooqinn
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
|
Kubernetes integration test starting |
|
Kubernetes integration test status failure |
|
Test build #144535 has finished for PR 34365 at commit
|
| properties = table.properties ++ properties, | ||
| comment = properties.get(TableCatalog.PROP_COMMENT).orElse(table.comment)) | ||
| catalog.alterTable(newTable) | ||
| catalog.invalidateCachedTable(tableName) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would it be better to do this inside SessionCatalog.alterTable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you @sunchao . I think it's a code improvement, and if we decide to do that, it should consider more methods include alterTableDataSchema, alterPartition, etc. So for now in this PR, I prefer do the simple fix which is straightforward.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. This looks good to me. I'm just curious whether other alter table variants have the same issue.
### What changes were proposed in this pull request?
Invalidate the table cache after alter table properties (set and unset).
### Why are the changes needed?
The table properties can change the behavior of wriing. e.g. the parquet table with `parquet.compression`.
If you execute the following SQL, we will get the file with snappy compression rather than zstd.
```
CREATE TABLE t (c int) STORED AS PARQUET;
// cache table metadata
SELECT * FROM t;
ALTER TABLE t SET TBLPROPERTIES('parquet.compression'='zstd');
INSERT INTO TABLE t values(1);
```
So we should invalidate the table cache after alter table properties.
### Does this PR introduce _any_ user-facing change?
yes, bug fix
### How was this patch tested?
Add test
Closes #34365 from ulysses-you/SPARK-37098.
Authored-by: ulysses-you <[email protected]>
Signed-off-by: Kent Yao <[email protected]>
(cherry picked from commit 02d3b3b)
Signed-off-by: Kent Yao <[email protected]>
### What changes were proposed in this pull request?
Invalidate the table cache after alter table properties (set and unset).
### Why are the changes needed?
The table properties can change the behavior of wriing. e.g. the parquet table with `parquet.compression`.
If you execute the following SQL, we will get the file with snappy compression rather than zstd.
```
CREATE TABLE t (c int) STORED AS PARQUET;
// cache table metadata
SELECT * FROM t;
ALTER TABLE t SET TBLPROPERTIES('parquet.compression'='zstd');
INSERT INTO TABLE t values(1);
```
So we should invalidate the table cache after alter table properties.
### Does this PR introduce _any_ user-facing change?
yes, bug fix
### How was this patch tested?
Add test
Closes #34365 from ulysses-you/SPARK-37098.
Authored-by: ulysses-you <[email protected]>
Signed-off-by: Kent Yao <[email protected]>
(cherry picked from commit 02d3b3b)
Signed-off-by: Kent Yao <[email protected]>
|
thanks, merged to master/3.2/3.1. |
|
It conflicts 3.0, would you please backport it @ulysses-you ? |
|
thank you all, created #34379 |
|
+1, LGTM. Thank you, @ulysses-you and all. |
This pr can't be merged into branch-3.1 directly too, there is an error below: in |
|
@zzcclp Thanks for reporting this. I created 05aea97 to revert it from branch-3.1. @ulysses-you would you please also send a PR target 3.1 again? |
|
created #34390 for banchr-3.1 |
This PR backport #34365 to branch-3.1 ### What changes were proposed in this pull request? Invalidate the table cache after alter table properties (set and unset). ### Why are the changes needed? The table properties can change the behavior of wriing. e.g. the parquet table with `parquet.compression`. If you execute the following SQL, we will get the file with snappy compression rather than zstd. ``` CREATE TABLE t (c int) STORED AS PARQUET; // cache table metadata SELECT * FROM t; ALTER TABLE t SET TBLPROPERTIES('parquet.compression'='zstd'); INSERT INTO TABLE t values(1); ``` So we should invalidate the table cache after alter table properties. ### Does this PR introduce _any_ user-facing change? yes, bug fix ### How was this patch tested? Add test Closes #34390 from ulysses-you/SOARK-37098-3.1. Authored-by: ulysses-you <[email protected]> Signed-off-by: Dongjoon Hyun <[email protected]>
This PR backport #34365 to branch-3.0 ### What changes were proposed in this pull request? Invalidate the table cache after alter table properties (set and unset). ### Why are the changes needed? The table properties can change the behavior of wriing. e.g. the parquet table with `parquet.compression`. If you execute the following SQL, we will get the file with snappy compression rather than zstd. ``` CREATE TABLE t (c int) STORED AS PARQUET; // cache table metadata SELECT * FROM t; ALTER TABLE t SET TBLPROPERTIES('parquet.compression'='zstd'); INSERT INTO TABLE t values(1); ``` So we should invalidate the table cache after alter table properties. ### Does this PR introduce _any_ user-facing change? yes, bug fix ### How was this patch tested? Add test Closes #34379 from ulysses-you/SPARK-37098-3.0. Authored-by: ulysses-you <[email protected]> Signed-off-by: Dongjoon Hyun <[email protected]>
### What changes were proposed in this pull request?
Invalidate the table cache after alter table properties (set and unset).
### Why are the changes needed?
The table properties can change the behavior of wriing. e.g. the parquet table with `parquet.compression`.
If you execute the following SQL, we will get the file with snappy compression rather than zstd.
```
CREATE TABLE t (c int) STORED AS PARQUET;
// cache table metadata
SELECT * FROM t;
ALTER TABLE t SET TBLPROPERTIES('parquet.compression'='zstd');
INSERT INTO TABLE t values(1);
```
So we should invalidate the table cache after alter table properties.
### Does this PR introduce _any_ user-facing change?
yes, bug fix
### How was this patch tested?
Add test
Closes apache#34365 from ulysses-you/SPARK-37098.
Authored-by: ulysses-you <[email protected]>
Signed-off-by: Kent Yao <[email protected]>
(cherry picked from commit 02d3b3b)
Signed-off-by: Kent Yao <[email protected]>
(cherry picked from commit b7948ee)
This PR backport apache#34365 to branch-3.1 ### What changes were proposed in this pull request? Invalidate the table cache after alter table properties (set and unset). ### Why are the changes needed? The table properties can change the behavior of wriing. e.g. the parquet table with `parquet.compression`. If you execute the following SQL, we will get the file with snappy compression rather than zstd. ``` CREATE TABLE t (c int) STORED AS PARQUET; // cache table metadata SELECT * FROM t; ALTER TABLE t SET TBLPROPERTIES('parquet.compression'='zstd'); INSERT INTO TABLE t values(1); ``` So we should invalidate the table cache after alter table properties. ### Does this PR introduce _any_ user-facing change? yes, bug fix ### How was this patch tested? Add test Closes apache#34390 from ulysses-you/SOARK-37098-3.1. Authored-by: ulysses-you <[email protected]> Signed-off-by: Dongjoon Hyun <[email protected]>
### What changes were proposed in this pull request?
Invalidate the table cache after alter table properties (set and unset).
### Why are the changes needed?
The table properties can change the behavior of wriing. e.g. the parquet table with `parquet.compression`.
If you execute the following SQL, we will get the file with snappy compression rather than zstd.
```
CREATE TABLE t (c int) STORED AS PARQUET;
// cache table metadata
SELECT * FROM t;
ALTER TABLE t SET TBLPROPERTIES('parquet.compression'='zstd');
INSERT INTO TABLE t values(1);
```
So we should invalidate the table cache after alter table properties.
### Does this PR introduce _any_ user-facing change?
yes, bug fix
### How was this patch tested?
Add test
Closes apache#34365 from ulysses-you/SPARK-37098.
Authored-by: ulysses-you <[email protected]>
Signed-off-by: Kent Yao <[email protected]>
(cherry picked from commit 02d3b3b)
Signed-off-by: Kent Yao <[email protected]>
### What changes were proposed in this pull request?
Invalidate the table cache after alter table properties (set and unset).
### Why are the changes needed?
The table properties can change the behavior of wriing. e.g. the parquet table with `parquet.compression`.
If you execute the following SQL, we will get the file with snappy compression rather than zstd.
```
CREATE TABLE t (c int) STORED AS PARQUET;
// cache table metadata
SELECT * FROM t;
ALTER TABLE t SET TBLPROPERTIES('parquet.compression'='zstd');
INSERT INTO TABLE t values(1);
```
So we should invalidate the table cache after alter table properties.
### Does this PR introduce _any_ user-facing change?
yes, bug fix
### How was this patch tested?
Add test
Closes apache#34365 from ulysses-you/SPARK-37098.
Authored-by: ulysses-you <[email protected]>
Signed-off-by: Kent Yao <[email protected]>
(cherry picked from commit 02d3b3b)
Signed-off-by: Kent Yao <[email protected]>
What changes were proposed in this pull request?
Invalidate the table cache after alter table properties (set and unset).
Why are the changes needed?
The table properties can change the behavior of wriing. e.g. the parquet table with
parquet.compression.If you execute the following SQL, we will get the file with snappy compression rather than zstd.
So we should invalidate the table cache after alter table properties.
Does this PR introduce any user-facing change?
yes, bug fix
How was this patch tested?
Add test