__System info:__
InfluxDB v1.6.4
CentOS Linux release 7.5.1804 (Core)
__Steps to reproduce:__
In a SELECT INTO statement, use the STDDEV aggregation function over a bucket containing exactly one data point, as in the following test case:
curl -X POST 'http://localhost:8086/query' -d 'q=CREATE DATABASE test_case'
curl -X POST 'http://localhost:8086/write?db=test_case&precision=s' -d 'weather temp=10 1510177750'
curl -X POST 'http://localhost:8086/query' -d 'db=test_case&q=SELECT mean(*),stddev(*) INTO weather_daily FROM weather GROUP BY time(1d), * fill(none)'
curl -X POST 'http://localhost:8086/query' -d 'db=test_case&q=SHOW FIELD KEYS'
__Expected behavior:__
I would expect that if the field stddev_temp in weather_daily is created at all, it should be created with a numeric type, as it would be if the number of items in the bucket was anything other than 1. (Since it seems InfluxDB includes Bessel's correction and InfluxDB does not support NaN or Infinity, not being created at all seems most natural to me.)
__Actual behavior:__
The field stddev_temp is created with type string, as we can see with a SHOW FIELD KEYS:
{
"name": "weather_daily",
"columns": [ "fieldKey", "fieldType" ],
"values": [
[ "mean_temp", "float" ],
[ "stddev_temp", "string" ]
]
}
In more complicated cases, this issue can lead to a SELECT INTO failing due to a field type conflict if some buckets return a string and others a float:
ERR: partial write: field type conflict: input field "stddev_temp" on measurement "weather_daily" is type string, already exists as type float
...or creating fields with the same name but different types in different temporal shards:
name: weather_daily
fieldKey fieldType
-------- ---------
mean_temp float
stddev_temp float
stddev_temp string
Ran into this exact problem with my downsampling queries that sang the stdev()
ERR: write failed: partial write: field type conflict: input field "stddev_Active.KB" on measurement "foo" is type string, already exists as type float dropped=2
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Looks like this was fixed. Running my test case on v1.7.7 results in no stddev_temp field being created:
> show field keys;
name: weather
fieldKey fieldType
-------- ---------
temp float
name: weather_daily
fieldKey fieldType
-------- ---------
mean_temp float
Most helpful comment
Ran into this exact problem with my downsampling queries that sang the stdev()