Bug #101530 | Partition pruning fails with explicit time_zone offset in datetime literal | ||
---|---|---|---|
Submitted: | 9 Nov 2020 22:49 | Modified: | 27 Apr 2021 23:22 |
Reporter: | Mattias Jonsson (OCA) | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Partitions | Severity: | S2 (Serious) |
Version: | 8.0.22 | OS: | Linux |
Assigned to: | CPU Architecture: | Any |
[9 Nov 2020 22:49]
Mattias Jonsson
[10 Nov 2020 4:40]
MySQL Verification Team
Hello Mattias, Thank you for the report and feedback! regards, Umesh
[27 Apr 2021 23:22]
Jon Stephens
Documented fix as follows in the MySQL 8.0.26 changelog: When a table was partitioned by timestamp and a timestamp literal with time zone was used in the WHERE clause of a SELECT statement, it was possible for a partition to be omitted from the result set. When a time zone offset is specified in a timestamp literal, it is expected to be converted to a timestamp without a time zone offset, and then compared against a timestamp column, but this was not done properly in all cases, with the result that a partition could be pruned while selecting the partitions to be scanned for the query. We fix this by making sure that a timestamp with a time zone offset is always converted as described before comparing with values from the column. Closed.