0

Deleting the influxdb entries which have some value for particular field and field exist in the entry.

delete from stats_io where _field='read_val'

This query doesn't throw any error and it doesn't delete any entries as well. But the field exist in all entries in influxdb.

delete from stats_io where _field="read_val"

Changing _field value from single to double quote ends up in an error.

ERR: shard 517: fields not supported in WHERE clause during deletion

I refer the documentation for delete predicate and it's possible to delete based on field exist. I am not sure why this error is happening ?

Influxdb-Version: 1.3.1

Any suggestion in figuring out the error is much appreciated. Thanks!

Rajan
  • 416
  • 1
  • 7
  • 25
  • This [ticket](https://github.com/influxdata/influxdb/issues/3210) seems to be related linked from [here](https://stackoverflow.com/a/39694049/13825434). So I'm going to guess that this is `something like` the issue between strings and string literals, one may interpreted as a string of text but one is interpreted as a string object or something of that nature. – Xinthral Jan 02 '21 at 21:44
  • @Xinthral Thanks for the links. My concern here is delete based on the predicate is not happening. The predicate '_filed' should match with entries having 'read_val' field. But removal of those entries doesn't happen. Suppose time range specified with where query delete properly removes the entries. Documentation similar have examples. The link which you shared shows the time range delete. I doubted it's not much related to delete based on field predicates. – Rajan Jan 04 '21 at 05:18
  • Okay, so it took me some time to read through the [documentation](https://docs.influxdata.com/influxdb/v1.8/query_language/manage-database/#delete-series-with-delete), because the syntax appears to be correct. Next would be troubleshooting and I would start by checking that delete's work without the predicate to see if something isn't going wrong in the _permissions_tmp_table_. – Xinthral Jan 05 '21 at 21:00
  • Duplicate the table and see if you can perform `DELETE FROM stats_io_duplicate;` to confirm that it's not a schema issue. Lastly I would go back over the `SHOW CREATE TABLE stats_io` to ensure there isn't some kind of key conflict or cascade constraint. Could always print out `_filed` datatype to make sure it does match `read_val`. After that, I am kind of out of ideas without being able to replicate the issue. – Xinthral Jan 05 '21 at 21:01

0 Answers0