-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should not be able to panic the database by using particular field keys #3010
Comments
@shaileshswapnil -- we need more detail. Can you please show us the sequence of problematic commands using https://github.com/influxdb/influxdb/blob/master/CONTRIBUTING.md#bug-reports |
Sequence of generating the bug/issue
After querying the time, which generally we can not do I guess, the influx service is affected and not allowing me to perform any query without restarting. OS: Linux centos65 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Influx version: 0.9 Installed it using wget |
|
In addition you are using a string when setting https://influxdb.com/docs/v0.9/concepts/reading_and_writing_data.html You may actually wish changing to the line protocol, since the JSON API is deprecated. |
For the record, the panic that is occurring is as follows:
|
@shaileshswapnil -- if you want to get the times back, you have to |
Okay And for the time field which you have mentioned that it is a reserved field, I am specifying it inside the "fields":{ }, so it should be treated as user defined value and can have either string or integer or decimal or whatever user will define. Not as reserved time field which is outside of "fields":{ } Yes JSON API is deprecated but still we can tweak according to the usability, similar to 0.8. |
@shaileshswapnil I've verified that even double-quoting the field key still causes a database panic, which is not good. We seem to handle
InfluxDB panicked on both of the last SELECT statements with |
Well.. seems the problem has been identified. Waiting to get it fixed soon along with proper error message while using reserved fields or some improper query. It must identify the illogical query and either return relevant result or prompt to user. Will be happy if I can contribute anything regarding this issue or other. |
The fix is either to ban the use of certain words as field keys, prevent the database from panicking when someone does so, or both. Not yet decided what the solution will be. In the meantime the workaround is trivial. Don't use any query language literal as a tag or field key. |
Test case with 127.0.0.1. |
Hi,
I was trying to include field named "time" which is similar to the predefined "time" field.
While doing so, it didn't gave any error. But while querying the "time" from the measurement, it gave error and after that no single query is executing, even "select" or "show measurements" not working.
So, I need to go to the /etc/init.d/ and restart the service.
Can anyone explain this issue?
The text was updated successfully, but these errors were encountered: