https://linen.dev logo
Join Slack
Powered by
Hi, I am still have <this> problem reproducible at...
# issues
v
Hi, I am still have this problem reproducible at my laptop. Let me know if any details you need to be able reproduce it at your end. I am running greptimedb standalone on my laptop in kind cluster. The table now has 1,202,640 rows, but I was facing the same problem on Friday with just 600,000. I am able to query this table with simple queries, but the moment I am adding ORDER BY the database crashes with 2025-12-22T142430.453876Z ERROR common_telemetry:panic hook panicked at /root/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/arrow-buffer-56.2.0/src/buffer/scalar.rs7052: offset overflow backtrace= 0: common_telemetry:panic hookset panic hook:{{closure}}
Copy code
1: std::panicking::panic_with_hook
   2: std::panicking::panic_handler::{{closure}}
   3: std::sys::backtrace::__rust_end_short_backtrace
   4: __rustc::rust_begin_unwind
   5: core::panicking::panic_fmt
   6: core::option::expect_failed
   7: arrow_buffer::buffer::scalar::ScalarBuffer<T>::new
   8: <arrow_array::array::byte_array::GenericByteArray<T> as arrow_array::array::Array>::slice
   9: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
  10: query::part_sort::PartSortStream::can_stop_early
  11: query::part_sort::PartSortStream::split_batch
  12: <query::part_sort::PartSortStream as futures_core::stream::Stream>::poll_next
  13: query::window_sort::WindowedSortStream::poll_next_inner
  14: <query::window_sort::WindowedSortStream as futures_core::stream::Stream>::poll_next
  15: datafusion_common_runtime::trace_utils::trace_future::{{closure}}
  16: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll
  17: tokio::runtime::task::core::Core<T,S>::poll
  18: tokio::runtime::task::harness::Harness<T,S>::poll
  19: tokio::runtime::scheduler::multi_thread::worker::Context::run_task
  20: tokio::runtime::context::scoped::Scoped<T>::set
  21: tokio::runtime::context::runtime::enter_runtime
  22: tokio::runtime::scheduler::multi_thread::worker::run
  23: <tokio::runtime::blocking::task::BlockingTask<T> as core::future::future::Future>::poll
  24: tokio::runtime::task::core::Core<T,S>::poll
  25: tokio::runtime::task::harness::Harness<T,S>::poll
  26: tokio::runtime::blocking::pool::Inner::run
  27: std::sys::backtrace::__rust_begin_short_backtrace
  28: core::ops::function::FnOnce::call_once{{vtable.shim}}
  29: std::sys::thread::unix::thread::new::thread_start
  30: <unknown>
  31: <unknown>
 panic.file="/root/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/arrow-buffer-56.2.0/src/buffer/scalar.rs" panic.line=70 panic.column=52
Well, this is embarrassing.

GreptimeDB had a problem and crashed. To help us diagnose the problem you can send us a crash report.
and this is a query and the table:
Copy code
CREATE TABLE IF NOT EXISTS "node_cpu_guest_seconds_total" (
  "cpu" STRING NULL,
  "greptime_timestamp" TIMESTAMP(3) NOT NULL,
  "greptime_value" DOUBLE NULL,
  "instance" STRING NULL,
  "job" STRING NULL,
  "k8s_cluster_name" STRING NULL,
  "mode" STRING NULL,
  "service_instance_id" STRING NULL,
  "service_name" STRING NULL,
  TIME INDEX ("greptime_timestamp"),
  PRIMARY KEY ("cpu", "instance", "job", "k8s_cluster_name", "mode", "service_instance_id", "service_name")
)

ENGINE=metric
WITH(
  'comment' = 'Created on insertion',
  on_physical_table = 'greptime_physical_table',
  otlp_metric_compat = 'prom'
)
Copy code
SELECT 
    *
FROM node_cpu_guest_seconds_total 
ORDER BY greptime_timestamp DESC 
LIMIT 5;
If I slightly change the query to
Copy code
SELECT greptime_timestamp, cpu 
FROM node_cpu_guest_seconds_total 
ORDER BY greptime_timestamp DESC ;
it runs successfully
I also updated my deployment to beta3 but still able to reproduce the issue. Current version:
Copy code
branch: 
commit: 1afcddd5a9d66f7ba9d3739cc51bee990ea58f04
commit_short: 1afcddd5a
clean: true
version: 1.0.0-beta.3
I am now able to run
Copy code
SELECT greptime_timestamp, cpu 
FROM node_cpu_guest_seconds_total 
ORDER BY greptime_timestamp DESC ;
LIMIT 5;
but not
Copy code
SELECT 
    *
FROM node_cpu_guest_seconds_total 
ORDER BY greptime_timestamp DESC 
LIMIT 5;
e
We haven’t reproduced this yet. Do you mind tar your data directory (the whole data_home) and sending it to me?
đź‘€ 1
2 Views
Open in Slack
PreviousNext
Powered by