Hello,
I was trying to alter many 135 partitions to PARQUET on QDB 9.3.0 / Windows 11. At some point, it keeps crashing. In the logs I see:
2026-01-12T10:37:47.109109Z I i.q.c.TableWriter switched partition [path=\nimes_qcia0001_object_stat~148\2025-12-08.554923, rowCount=569]
2026-01-12T10:37:47.126585Z I i.q.c.TableWriter converting partition to parquet [path=\nimes_qcia0001_object_stat~148\2025-04-08.336553]
…
thread ‘’ (9012) panicked at src\parquet_write\varchar.rs:84:17:
Data corruption in VARCHAR column
stack backtrace:
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
thread ‘’ (9012) panicked at library\core\src\panicking.rs:228:5:
panic in a function that cannot unwind
stack backtrace:
0: 0x7fff882f1ba2 -
1: 0x7fff8830735a -
2: 0x7fff882b85be -
3: 0x7fff882d0cf5 -
4: 0x7fff882d8679 -
5: 0x7fff882d8468 -
6: 0x7fff882d8fbb -
7: 0x7fff882d8d52 -
8: 0x7fff882d0eef -
9: 0x7fff882b2f7e -
10: 0x7fff88395915 -
11: 0x7fff883957c3 -
12: 0x7fff88395a91 -
13: 0x7fff88072201 -
14: 0x7fff9a651030 -
15: 0x7fff9a654828 -
16: 0x7fffa3c74726 -
17: 0x7fff880718af -
18: 0x1bea311d141 -
thread caused non-unwinding panic. aborting.
How can I stop the conversion as it tries at every reboot of the service and always crashes after a few seconds ?
Also in the documentation it is written:
https://questdb.com/docs/query/export-parquet/#converting-from-parquet-into-native-format#code-9-chunk-0
zstd
cairo.partition.encoder.parquet.compression.codec=6
level is from 1 to 22, 1 is fastest
cairo.partition.encoder.parquet.compression.level=10
While the format for the expected format for the codec is a string (https://questdb.com/docs/configuration/overview/#cairo-engine#table-3-chunk-8)
Hey Gabriel, that’s a worrying issue.
First of all, try setting cairo.wal.apply.enabled=false in your config. This will stop the database retrying any transactions in the WAL. Fingers crossed this should allow you to boot up.
Then you need to either suspend the table and skip the txns, or just convert the table to non-WAL and back again. If you don’t have a lot of data backed up in the WAL, then you can follow the BYPASS WAL docs: ALTER TABLE SET TYPE | QuestDB
Then once all is well, re-enable WalApplyJob and restart the database one final time.
Once you are stable, please send on detailed server logs/crash logs. These can be emailed to support@questdb.com, so we can look into the issue and determine what went wrong.
Hi Nick,
Disabling the WAL was useful to recover.
Then I had few partitions in a row that could not be read at all with the following log:
2026-01-15T16:12:23.525498Z I i.q.g.e.QueryProgress exe [id=441, sql=SELECT * FROM nimes_qcia0001_object_stat WHERE timestamp IN '2025-04-08', principal=admin, cache=false, jit=false]
2026-01-15T16:12:23.526769Z C i.q.c.h.p.JsonQueryProcessorState [31870804823891] error [msg=varchar is outside of file boundary [dataLim=0, dataLo=0, size=36], errno=0, q=SELECT * FROM nimes_qcia0001_object_stat WHERE timestamp IN '2025-04-08']
2026-01-15T16:12:23.526863Z I i.q.g.e.QueryProgress fin [id=441, sql=SELECT * FROM nimes_qcia0001_object_stat WHERE timestamp IN '2025-04-08', principal=admin, cache=false, jit=true, time=1369800]
2026-01-15T16:12:23.526899Z I i.q.c.h.p.JsonQueryProcessorState [31870804823891] timings [compiler: 2394800, count: 0, execute: 4013000, q=SELECT * FROM nimes_qcia0001_object_stat WHERE timestamp IN '2025-04-08']
Seeing it is linked to a varchar, I suspect the issue was created when altering a column from STRING to VARCHAR when this was released. I detached those partitions and the rest was working properly.
Hopefully, it is on test data… so it is not affecting real data.
Hey Gabriel,
Those look like corruptions indeed. This usually requires dropping and reloading the partition, and/or restoring from backup unfortunately. Did you happen to run out of disk space (or have similar issues) before the panic?