CRash when attempting to SELECT INTO

[pbooth]

I'm having some issues when trying to combine data from different measurements.
I'm finding that the attempt to select into a measurement in the
crash.txt
same database consistently crashes with the attached error

[query] 2016/02/26 11:57:37 SHOW DATABASES
[http] 2016/02/26 11:57:37 127.0.0.1 - - [26/Feb/2016:11:57:37 -0500] GET /query?db=&epoch=ns&q=SHOW+DATABASES HTTP/1.1 200 137 - InfluxDBShell/0.10.0 0a1607ba-dcaa-11e5-8e4e-000000000000 437.925µs
[query] 2016/02/26 11:58:03 SELECT value AS value INTO integration4."default".plat FROM integration4."default".prism_latencies WHERE env = 'prod' AND time > '2016-02-24T08:00:00Z' GROUP BY *
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x63e495]

goroutine 43781 [running]:
github.com/influxdb/influxdb/tsdb.(_RawExecutor).execute(0xc25fcfbb60, 0xc478b80840, 0xc269e6d5c0)
/tmp/tmp.r1Nea5VXEw/src/github.com/influxdb/influxdb/tsdb/raw.go:229 +0xf55
created by github.com/influxdb/influxdb/tsdb.(_RawExecutor).Execute
/tmp/tmp.r1Nea5VXEw/src/github.com/influxdb/influxdb/tsdb/raw.go:59 +0x64

[zstyblik]

@pbooth, please, can you provide version of InfluxDB as well?

[pbooth]

Sure, it's the recent 0.10.0 release. I've subsequently done done testing to try and work around the issue:

I had been working with default retention policies and, on a hunch I created explicit three_month and two_year policies. On some occasions, using explicit retention policies appeared to prevent the crash but I haven't been able to see a pattern to this.

Sent from my iPhone

On Feb 26, 2016, at 3:18 PM, Zdenek Styblik notifications@github.com wrote:

@pbooth, please, can you provide version of InfluxDB as well?

—
Reply to this email directly or view it on GitHub.

[jonseymour]

This looks like #5303 which was fixed in 0.10.1

[pbooth]

I repeated the same operation on a different host, after upgrading to 0.10.1 and did not get a crash

[zstyblik]

@pbooth that's good news! Can this issue be eventually closed then, if it's resolved?

[pbooth]

Definitely. I attempted another similar operatin on both 0.10.0 and 0.10.1 and it worked on 0.10.1 whilst failing on 0.10.0.

PS - the increase in performance, stability, and functionality from 0.8 to 0.9 to 0.10 is astounding.
Its great that rrd, graphite, ganglia are now distant bleak memories.

[toddboom]

@pbooth Thanks for the update. It sounds like it's safe to close this out now.

Glad to hear that you're pleased with the performance. We'll keep making it even better!