"found" by the @discordapp troops the hard way: https://status.discordapp.com/incidents/62gt9cgjwdgf
pinging @zorkian who pointed it out to me.

trivial to repro, this is against a 3.3.13 on fedora-31.

$ etcdctl set /baa schnorp
$ etcdctl get /baa
schnorp
$ echo -ne 'PUT /v2/keys/baa HTTP/1.1\r\nHost: boo\r\nContent-Length: 123\r\n\r\n' | nc localhost 2379
HTTP/1.1 200 OK
...
$ et

We do have the internal metadata concepts to make this happen in a relatively inexpensive way. That being said, we have not implemented this functionality. Please file a github issue to track it and discuss various design point. I will warn you that I don’t think this is something we’re in any hurry to implement. That issue can also be a way to gauge interest and work out syntax details. (by ajw

Hi,

This issue is to add a unit test for isAllTablesInSameDataSource method in shardingRule.

If you want to have an example, please refer to the test case for other method in ShardingRuleTest.

fdbcli flags currently contain a mixture of _ and - (probably for historic reasons). I would propose to unify the flags and only use either _ or - personally I tend to hyphens like recommended in the POSXI standard (https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html). Current fdbcli help output:

FoundationDB CLI 6.2 (v6.2.29)
usage: /usr/bin/fdb/6.2/fdbcli

Hello Philip!
I think there is an issue with this part of the code of rqlite (store/store.go).

func (s *Store) Database(leader bool) ([]byte, error) {
	if leader && s.raft.State() != raft.Leader {
		return nil, ErrNotLeader
	}
	// Ensure only one snapshot can take place at once, and block all queries.
	s.mu.Lock()
	defer s.mu.Unlock()

	f, err := ioutil.TempFile("", "rqlilte-snap-

At the moment the tservers are listed randomly in the tablet servers page in the master leader UI.
Its nice to have them grouped by availability zone to find the nodes easily on large clusters.

In io/trino/plugin/bigquery/ReadSessionCreator.java, TableInfo is getting cached for only 15 minutes. This makes sure for the next 15 minutes all the subsequent queries will use the cache.

I believe rather than hardcoding the TTL to 15 minutes, we should externalize this number so that it can be configured on a case-to-case basis.

Slack Thread: https://trinodb.slack.com/archives/CFLB9AMB

Use case:
Right now one can only use date_trunc() to easily define time buckets. date_trunc() only supports predefine time intervals like 1 minute, 1 hour, etc. . In time-series use cases it is often necessary to define different time bucket sizes like e.g. '5 minutes' or '20 minutes'

a workaround for this is the - error prone - integer division on the timestamp e.g.

S

Currently we don't have any mechanism to limit the maximum number of clients that could be handled simultaneously.

This feature should be designed properly. Here is some clue: https://redis.io/topics/clients#maximum-number-of-clients

Now that we support more than 1 data type, we should include the values data type in cache nodes. This give us a way of easily identifying what type of data a key points to e.g. string, queue (and more types in the future)

Currently a cache node object consists of a Key, a Value and a TTL. We should also add a field specifying the type of the Value

日期转换函数timpstamp插入和保存都是int64，后面是否会支持yyyy-MM-dd HH:mm:ss这种形式，同时支持内部日期函数转换，将int64转换成yyyy-MM-dd HH:mm:ss。对于int64，现在的解决措施只能是应用内转换和新建string字段展示正常的日期格式