Influxdb: queries returning messed up column names

[phemmer]

Apologies for horrible title, have no concise way to describe what I'm seeing.

Bug report

System info:
influxdb 1.0 beta 3
CentOS/7 x86_64

Steps to reproduce:

1. select * from mymeasurement

Expected behavior: [What you expected to happen]
Receive correct column names

Actual behavior: [What actually happened]
One of the expected columns has _1 appended to it.

Additional info: [Include gist of relevant config, logs, etc.]
This is an example insert:

postgresql_databases,database=postgres,group=gdbs,host=iad1gdbs01,location=iad1,os=FreeBSD blk_read_time=0,blk_write_time=0,blks_hit=863929036i,blks_read=1611i,conflicts=0i,deadlocks=0i,numbackends=1i,temp_bytes=0i,temp_files=0i,tup_deleted=0i,tup_fetched=405057875i,tup_inserted=0i,tup_returned=506686415i,tup_updated=0i,xact_commit=7980561i,xact_rollback=90638i 1474066069202000000

Here's the output of a select:

> select * from postgresql_databases where time > now() - 1m
name: postgresql_databases
--------------------------
time                    blk_read_time   blk_write_time  blks_hit        blks_read       conflicts       database        database_1      deadlocks       env     group   host            location        numbackends     os      temp_bytes      temp_files      tup_deleted     tup_fetched     tup_inserted    tup_returned    tup_updated     xact_commit     xact_rollback
1474066535068000000     0               0               21754069437     2411181212      0                               denver          0                       gdbs    iad1gdbs03      iad1            0               Linux   2778440853454   110155          0               15422765558     0               165947444223    0               581097          752
1474066535068000000     0               0               30305384        297             0                               postgres        0                       gdbs    iad1gdbs03      iad1            1               Linux   0               0               0               15896586        0               15935938        0               234910          0
1474066535068000000     0               0               0               0               0                               sessions        0                       gdbs    iad1gdbs03      iad1            0               Linux   0               0               0               0               0               0               0               0               0
1474066535726000000     0               0               1196039941      5614            0                               postgres        0                       gdbs    iad1gdbs02      iad1            1               FreeBSD 0               0               0               562679893       0               689582443       0               16081429        49943
1474066535726000000     0               0               17355290436     1188625659      51                              denver          0                       gdbs    iad1gdbs02      iad1            0               FreeBSD 2801879793311   85479           0               20782405500     0               116456344495    0               1243071         431
1474066535726000000     0               0               215945218       6522            0                               sessions        0                       gdbs    iad1gdbs02      iad1            0               FreeBSD 0               0               0               97489928        0               261962611       0               786330          0
1474066541501000000     0               0               155196239       239             0                               postgres        0                       kdbu    iad1kdbu01      iad1            1               FreeBSD 0               0               0               82169108        0               285502974       0               875909          191616
1474066549274000000     0               0               864046661       1611            0                               postgres        0                       gdbs    iad1gdbs01      iad1            1               FreeBSD 0               0               0               405112983       0               506755662       0               7981649         90648
1474066549274000000     0               0               1691637698      162666631       0                               sessions        0                       gdbs    iad1gdbs01      iad1            20              FreeBSD 0               0               85915491        159475201       85915957        739847886       8956436         16549066        4
1474066549274000000     0               0               310765702404    6083081458      0                               denver          291                     gdbs    iad1gdbs01      iad1            153             FreeBSD 1353733887817   56055           99531230        335494389898    249909043       1151265574638   259918676       854287759       12567178
1474066564452000000     0               0               100624965       467             0                               postgres        0                       gdbp    iad1gdbp01      iad1            1               Linux   0               0               0               53670677        0               148832751       14              555096          109986
1474066564453000000     0               0               90189558407     2727722460      0                               pricebot        103                     gdbp    iad1gdbp01      iad1            15              Linux   1200830491073   2270            809926205       83440420264     947380758       2246038580453   461810522       150412718       15192

Notice how the database column is empty, and we instead have a database_1.
This gets even weirder if you try to select these columns:

> select "database","database_1",xact_commit from postgresql_databases where time > now() - 1m
name: postgresql_databases
--------------------------
time                    database        database_1      xact_commit
1474066535068000000                                     581097
1474066535068000000                                     234910
1474066535068000000                                     0
1474066535726000000                                     16081429
1474066535726000000                                     1243071
1474066535726000000                                     786330
1474066541501000000                                     875909
1474066549274000000                                     7981649
1474066549274000000                                     16549066
1474066549274000000                                     854287759
1474066564452000000                                     555096
1474066564453000000                                     150412718

And if you try to use the columns, also nothing:

> select * from postgresql_databases where time > now() - 1m and "database"='postgres';
> select * from postgresql_databases where time > now() - 1m and "database_1"='postgres';
> 

[phemmer]

I just upgraded to 1.0.0 (not beta3), and issue is still present.

I should also note that this was working just fine for weeks. It just all of a sudden started using database_1 for no apparent reason.
Oh, and this appears to be just a query issue. Data which was inserted and querying fine prior to this issue showing up is also now coming back with the column name messed up.

[phemmer]

The problem just as suddenly went away. Nothing was changed. It just stopped.
However, I took a filesystem snapshot while the issue was present, and starting influxdb up with this snapshot still shows the issue.

[jsternberg]

@phemmer is it possible for me to get that dataset? Also, query logging should print out the expanded query. Can you paste the log output related to this query?

[phemmer]

Unfortunately the data is now gone. Was on an LVM snapshot, and the snapshot ran out of space early this morning, and was destroyed.
I'll keep an eye out for the problem and capture the requested info when it happens again.

As for getting the data to you, I'm not sure. It's several GB, so it's not easy to move around, unless there is some way of only grabbing the relevant data.

[jsternberg]

Ok, if it happens again, please comment here and I'll reopen the issue. I'm going to close this as not able to reproduce.

[psi-4ward]

I had a similar issue with rows like row and row_1
My error was to define row as _Tag_ and _Field_

[jdkealy]

I just installed influx and this happened pretty much immediately. I never added a column symbol_1

I'm on 1.1.0 and using a Clojure client. I can try to recreate via the linux client.

A little about what I did... I queried 50k rows from a database and added them one by one, forgive the fact that I'm copy pasting from my clojure client.

(let [vals  {:measurement "quotes"
                             :tags        {"type" type "symbol" symbol}
                             :fields      {"size" size "price" price }
                             :timestamp   trade_time}]
                  (write-point connection ))

[jdkealy]

Just like previous poster, this issue went away as soon as I restarted my machine.

[dandv]

Unlike the previous posters,

• I absolutely did not have the same column as a field and a tag. It was always a tag - I simply did not change the code that was writing to the measurement, only the measurement name, but after I ran a SELECT * INTO newmeasuremnet FROM oldmeasurement, writes into newmeasurement (or queries from it) return all tags with _1 appended.
• The problem did not go away after restarting the Influx server.