Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
…index scans Summary: Previously, there were issues related to timestamp handling during insertions, particularly when timestamps were provided with microsecond precision. This occurred either through the use of the `currenttimestamp()` function or when explicitly inserting timestamps as strings with non-zero microseconds. These timestamps were stored in the storage layer (DocDB) with full microsecond precision, but the Cassandra layer only supports precision up to milliseconds. This mismatch in precision led to several issues: 1. Query mismatch in `SELECT` statements: When data was fetched using `SELECT * FROM table`, the timestamps were returned with millisecond precision (i.e., zeroed out microseconds). However, if users then used these returned timestamps in a `WHERE` clause to query the same table, no results would be returned. This occurred because the underlying storage still held the original timestamp with microseconds, causing a mismatch in the comparison. 2. Index scan failures with TIMESTAMP primary keys: In cases where a timestamp column was part of a primary key, performing an index scan using a secondary index would fail. This is because during an index scan, the data retrieved from the index includes the primary key, which, after passing through the Cassandra layer, was reduced to millisecond precision. When this primary key was then used to fetch data from the storage layer (DocDB), the keys no longer matched due to the precision difference. This revision addresses these two issues by ensuring that timestamps provided in microseconds are properly handled. Specifically: 1. `currenttimestamp()` function: Previously, this function returned the current time in microsecond precision, leading to inconsistencies. It now converts the timestamp to millisecond precision, aligning with Cassandra’s limitations. 2. String-specified timestamps with microsecond precision: When a timestamp is explicitly provided in a string format with microseconds (e.g., `2024-08-26 09:13:38.248513+0000`), it is now rounded down to the nearest millisecond (i.e., flooring the value). These fixes ensure that YCQL behaves more consistently with Cassandra, which does not support microseconds. To enable this behavior and use the original partial support for microseconds, the gflag `cql_revert_to_partial_microsecond_support=false` must be set. This flag is set to `true` by default but can be turned off to store timestamps inserted with microseconds precision in nearest millisecond. Irrespective of the value of gflag, a warning will be logged every 300 secs, if there are any inserts of timestamp data with microseconds precision. JIRA: DB-1000, DB-12394 Test Plan: == Automated testing == ./yb_build.sh --java-test 'org.yb.cql.TestTimestampDataType#testTimestampMicrosecsInsertSelect' ./yb_build.sh --java-test 'org.yb.cql.TestTimestampDataType#testTimestampPKIndexScan' New Tests Added: **org.yb.cql.TestTimestampDataType#testTimestampMicrosecsInsertSelect** This test verifies that inserting a timestamp string with microseconds precision (e.g., `'2024-08-26 09:13:38.248513+0000'`) allows fetching the corresponding row using a `WHERE` clause with the nearest millisecond value (e.g., `WHERE col = '2024-08-26 09:13:38.248000+0000'`). **org.yb.cql.TestTimestampDataType#testTimestampPKIndexScan** This test checks the behavior for a table with a primary key on a timestamp column and a secondary index. It inserts timestamp data using the `currenttimestamp()` function and explicit strings with microseconds precision. Then, an index scan using the secondary index is performed to fetch the data. Both tests pass only when the gflag `cql_revert_to_partial_microsecond_support=false` Reviewers: skumar, stiwary, pjain Reviewed By: skumar, pjain Subscribers: svc_phabricator, yql, ybase Differential Revision: https://phorge.dev.yugabyte.com/D37531
- Loading branch information