The playground's QuestDB VM runs 9.3.1, but the examples it serves come from the current repo, which needs 9.3.2+. Two entries in its own Example dropdown fail:
$ curl -sS -X POST 'https://clickbench-playground.clickhouse.com/api/query?system=questdb' \
--data-binary "SELECT length_bytes('abc');"
{"error":"unknown function name: length_bytes(STRING)","position":7}
$ curl -sS -X POST 'https://clickbench-playground.clickhouse.com/api/query?system=questdb' \
--data-binary 'SELECT build();'
Build Information: QuestDB 9.3.1, JDK 17.0.9, Commit Hash 5480b2d313653b591403df4c924a84ed9fcd6703
Q28 and Q29 use length_bytes(), which first shipped in 9.3.2. questdb/install has pinned 9.3.5 since #902; the snapshot predates that merge. (Reverting the queries to length() isn't the fix - URL and Referer aren't ASCII, so it would shift those answers by 2.8% and 5.1%.)
Fix:
curl -X POST http://localhost:8000/api/admin/provision/questdb
It will come back
handle_queries reads queries.sql from the repo checkout on the host, but the engine answering comes from a snapshot built when the system was first provisioned. provision-all.sh skips anything already snapshotted, and INSTALL.md documents re-provisioning only after agent or base-image changes. So git pull && provision-all.sh picks up new systems and never refreshes changed ones.
Nine systems pin an explicit version; five report live exactly what the repo pins. That's less reassuring than it looks - those five pins were last touched 2026-05-07..05-15, before provisioning, so they've had no chance to drift. QuestDB is the only one whose pin moved afterwards, and it's the one that drifted.
49 systems have had install/create.sql/queries.sql/load/start changes since 2026-05-20. Which of those predate their snapshot is visible to you and not to me.
I drafted a staleness check in #1145 - fingerprint each system's scripts at provision time, expose source_stale, let provision-all.sh re-kick the stale ones. Closed it since this is your infrastructure and you may want a different shape, but happy to revive.
The playground's QuestDB VM runs 9.3.1, but the examples it serves come from the current repo, which needs 9.3.2+. Two entries in its own Example dropdown fail:
Q28 and Q29 use
length_bytes(), which first shipped in 9.3.2.questdb/installhas pinned 9.3.5 since #902; the snapshot predates that merge. (Reverting the queries tolength()isn't the fix - URL and Referer aren't ASCII, so it would shift those answers by 2.8% and 5.1%.)Fix:
It will come back
handle_queriesreadsqueries.sqlfrom the repo checkout on the host, but the engine answering comes from a snapshot built when the system was first provisioned.provision-all.shskips anything already snapshotted, and INSTALL.md documents re-provisioning only after agent or base-image changes. Sogit pull && provision-all.shpicks up new systems and never refreshes changed ones.Nine systems pin an explicit version; five report live exactly what the repo pins. That's less reassuring than it looks - those five pins were last touched 2026-05-07..05-15, before provisioning, so they've had no chance to drift. QuestDB is the only one whose pin moved afterwards, and it's the one that drifted.
49 systems have had
install/create.sql/queries.sql/load/startchanges since 2026-05-20. Which of those predate their snapshot is visible to you and not to me.I drafted a staleness check in #1145 - fingerprint each system's scripts at provision time, expose
source_stale, letprovision-all.shre-kick the stale ones. Closed it since this is your infrastructure and you may want a different shape, but happy to revive.