- 26 8月, 2019 3 次提交
-
-
由 Hongze Cheng 提交于
-
由 Hongze Cheng 提交于
-
由 Hongze Cheng 提交于
-
- 24 8月, 2019 14 次提交
-
-
由 Jeff Tao 提交于
fix & enhancement for udp connection handling
-
由 陶建辉(Jeff) 提交于
-
由 johnnyhou327 提交于
-
由 johnnyhou327 提交于
-
由 johnnyhou327 提交于
-
由 haojun Liao 提交于
标点符号错误修正
-
由 johnnyhou327 提交于
-
由 johnnyhou327 提交于
-
由 johnnyhou327 提交于
-
由 johnnyhou327 提交于
-
由 johnnyhou327 提交于
-
由 haojun Liao 提交于
fix memory leak in taos_query_a
-
由 johnnyhou327 提交于
-
由 johnnyhou327 提交于
-
- 23 8月, 2019 4 次提交
-
-
由 weixin_48148422 提交于
restful commands with length between 65380 and 65536 can trigger this issue.
-
由 黄科 提交于
-
由 slguan 提交于
-
由 slguan 提交于
-
- 22 8月, 2019 8 次提交
- 21 8月, 2019 2 次提交
- 19 8月, 2019 1 次提交
-
-
由 slguan 提交于
-
- 18 8月, 2019 1 次提交
-
-
由 weixin_48148422 提交于
1. potential data race in `taosProcessMonitorTimer`: the issue does not exist at present because there's only one scheduler thread, which means there's no cocurrent calls to this function for a same `pMonitor`. but if more scheduler threads are created later, there's a data race issue in rare case. as threads number can be easily increased by increase the value of `taosTmrThreads`, it is very unlikely that the developer could realize this function need to be revised together. that's why i say it is a 'potential' issue. this issue happens in below scenario: a. scheduler thread1: `if (pSet)` is true and new timer is installed by `taosTmrReset`; b. scheduler thread1: `if (pMonitor->pSet == NULL)` is true but `taosTmrStopA` is blocked, either by the mutex of the timer or os thread scheduler. c. timer thread: 200ms elapse, new call to `taosProcessMonitorTimer` is initialized in scheduler thread2; d. scheduler thread2: `if (pMonitor->pTimer != tmrId)` is false; e. scheduler thread1: unblocked, stops timer and frees `pMonitor`; f. scheduler thread2: unexpected behavior because `pMonitor` is not valid any more. because the result of this issue is crash or worse, i suggest to fix it though the possibility of all the conditions are met is very very low. 2. `pthread_attr_t` related issues: per manual, an initialized `pthread_attr_t` can be reused, should be destroyed, and the behavior of re-init it is undefined. this issue exist in other modules also. 3. memory leaks; 4. improve failure case handling of `taosInitUdpConnection`; 5. typo
-
- 17 8月, 2019 3 次提交
-
-
由 Hongze Cheng 提交于
-
由 slguan 提交于
[taosdemo] repeat insertation if failed, report failure when inserting 5 times
-
由 slguan 提交于
Issue 349
-
- 16 8月, 2019 3 次提交
-
-
由 fang 提交于
-
由 plum-lihui 提交于
Update taosSqlCgo.go
-
由 liuliang 提交于
这个dbname都没有传进行,在连接池的情况下,每个连接都在选 use db. 当连接池切换连接时,就会出现 invalid DB。 ``` 8/16 12:44:46 dsn.go:59: input dsn: root:taosdata@/tcp(127.0.0.1)/sensors_test TAOS DRIVER 2019/08/16 12:44:46 dsn.go:130: cfg info: &{user:root passwd:taosdata net:/tcp addr:127.0.0.1 port:0 dbName:sensors_test params:map[] loc:0xed6be0 columnsWithAlias:false interpolateParams:true parseTime:true} TAOS DRIVER 2019/08/16 12:44:46 taosSqlCgo.go:52: taosQuery() input sql:INSERT INTO d_BDCF682B78F44364AA551B0F5E6BD1F6_acc USING acc_data TAGS ('BDCF682B78F44364AA551B0F5E6BD1F6','20190816- TAOS DRIVER 2019/08/16 12:44:46 taosSqlCgo.go:61: taos_query() failed: invalid DB ```
-
- 15 8月, 2019 1 次提交
-
-
由 hzcheng 提交于
enhance robustness of scheduler
-