Fix timestamps in system.runtime.queries #5465
Conversation
presto-tests/src/test/java/io/prestosql/connector/system/TestSystemConnector.java
Outdated
Show resolved
Hide resolved
findepi
force-pushed
the
findepi/queries
branch
2 times, most recently
from
06a8c43 to
857ae24
Compare
| @@ -62,7 +65,7 @@ public TransactionsSystemTable(Metadata metadata, TransactionManager transaction | |||
| .column("isolation_level", createUnboundedVarcharType()) | |||
| .column("read_only", BOOLEAN) | |||
| .column("auto_commit_context", BOOLEAN) | |||
| .column("create_time", TIMESTAMP_MILLIS) | |||
| .column("create_time", TIMESTAMP_TZ_MILLIS) | |||
There was a problem hiding this comment.
I am a bit concerned about backward compatibility of this change. Not sure how commonly are those system schemas used by Presto users.
|
|
||
| private static Long toTimestampWithTimeZoneMillis(DateTime dateTime) | ||
| { | ||
| if (dateTime == null) { |
presto-tests/src/test/java/io/prestosql/connector/system/TestSystemConnector.java
Show resolved
Hide resolved
findepi
force-pushed
the
findepi/queries
branch
from
857ae24 to
6e65422
Compare
|
AC |
|
LGTM |
| "SELECT max(created), max(started), max(last_heartbeat), max(\"end\") " + | ||
| "FROM system.runtime.queries"); | ||
| ZonedDateTime timeAfter = ZonedDateTime.now(); | ||
|
|
There was a problem hiding this comment.
We can do a sanity check to make the test failure reason obvious in case the system clock happens to be adjusted in between the calls
assertThat(timeAfter).isAfterOrEqualTo(timeBefore);There was a problem hiding this comment.
if the clock is adjusted, we still can fail, even if timeAfter >= timeBefore, so not sure how helpful it would be
| { | ||
| if (dateTime == null) { | ||
| return null; | ||
| } | ||
| return dateTime.getMillis() * MICROSECONDS_PER_MILLISECOND; | ||
| // dateTime.getZone() is the server zone, should be of no interest to the user |
There was a problem hiding this comment.
We used the server time zone for JmxRecordSetProvider since that seems like the right thing to return. If the administrator chooses to run their server in a specific time zone, then that's probably what they want to see when looking at system tables. cc @dain
There was a problem hiding this comment.
If we had an "instant" type, we would map to that. In the absence of "instant" type, we need to fill some zone, an we usually fill in UTC. eg
https://github.com/prestosql/presto/blob/fbd4ca7f6ca1326a077fd06cd33b687cbfe17cf2/presto-postgresql/src/main/java/io/prestosql/plugin/postgresql/PostgreSqlClient.java#L617
https://github.com/prestosql/presto/blob/91dbe5149ae593fc8f86d36a304f1f7e8dc9175c/presto-cassandra/src/main/java/io/prestosql/plugin/cassandra/CassandraRecordCursor.java#L109
There was a problem hiding this comment.
Also, the problem with server zone is that it may be a political zone.
Presto engine has no problem representing (point-in-time, zone) pairs.
However, due to how they are formatted for the client, client can no longer distinguish values within
summer→winter DST change.
presto> SELECT
-> increment,
-> from_unixtime(base + increment * 3600, 'America/Los_Angeles')
-> FROM (VALUES(1572766200)) t(base)
-> CROSS JOIN UNNEST(sequence(0, 3)) u(increment);
->
increment | _col1
-----------+---------------------------------------------
0 | 2019-11-03 00:30:00.000 America/Los_Angeles
1 | 2019-11-03 01:30:00.000 America/Los_Angeles
2 | 2019-11-03 01:30:00.000 America/Los_Angeles
3 | 2019-11-03 02:30:00.000 America/Los_Angeles
(4 rows)
findepi
force-pushed
the
findepi/queries
branch
from
6e65422 to
68fd4f8
Compare
findepi
force-pushed
the
findepi/queries
branch
from
68fd4f8 to
45c5329
Compare
|
CI failed -- #4936 |
Fixes #5462
Fixes #5464