What's new in QuestDB

When INSERT ... SELECT has a column list and a selected value cannot be converted, the "inconvertible types" error named the table column at that position in the list instead of the column the list names. For INSERT INTO t (c, a) SELECT ... on a table (a INT, b INT, c CHAR), the error said to=a while pointing at c, because SqlCompilerImpl read the column name with the list index.

This fix makes it use the table column index, as the type lookup next to it already did. Only the error text changes; which inserts succeed or fail stays the same.

An out-of-order commit that failed part-way, for example on a failed mmap, could crash the server, hang, or leave its tasks queued for the next commit, and failed deduplication commits could leak native memory or unmap memory they had not mapped. This fix addresses several causes. On tables with dropped columns, TableWriter and O3PartitionJob also subtracted dropped columns from the count of tasks in flight when publishing a partition's column tasks failed part-way, so the count could reach zero while a task still ran, causing the writer to unmap memory that task was reading, or skip zero so the commit never returned; both now count live columns only.

When the last column of an in-place append failed after the others had finished, TableWriter completed the partition twice, stopped waiting for the commit's other partitions and left their tasks queued for the next commit; the writer now leaves the count alone when no column is left unpublished. A failure while building partition paths, or a file release that threw during cleanup, could skip a count-down so the commit never returned; cleanup after a failed commit now logs a release that throws and carries on, so the commit fails with its original error, while a release that fails during an otherwise successful commit now fails the commit.

When an out-of-order merge failed to read deduplication keys beyond the designated timestamp, O3PartitionJob leaked the merge index, the key columns' file descriptors and a var-size key's aux mapping, and leaked them again on every failing RESUME WAL; it now hands each resource to its cleanup as soon as it acquires it.

Finally, when mapping a deduplication key's LAG rows failed, for example once vm.max_map_count ran out, TableWriter.deduplicateSortedIndex() released whatever the slot's last user had left there, which could unmap a range another mapping owned and later crash the server, or throw and replace the error that suspended the table; it now zeroes the slots and records each mapping as soon as it exists.

O3PartitionJob log messages that printed nanosecond timestamps as microseconds are also corrected.

HTTP clients can now follow Web Console redirects without timing out. With this fix the server marks redirect responses as empty and removes stray trailing bytes, allowing clients to reuse the connection.

This fix corrects several SAMPLE BY problems. With a copy of the timestamp or an expression over it in the select list, such as SELECT ts, ts AS ts2, count() ... SAMPLE BY 1d LIMIT 2, LIMIT took buckets in hash order instead of the first buckets in time, because the SAMPLE BY rewrite moved ORDER BY to a wrapper model but left LIMIT below it; rewriteSampleBy() now moves LIMIT to the wrapper as well, so it applies after the sort.

Moving LIMIT exposed an older bug in window resolution, where a lateral body failed with Invalid column: ts2 or sorted by the wrong column because doReplaceLiteral() resolved a window literal over a twice-selected column to an alias that only the inner virtual model exposes; rewriteSelectClause0() now renames these literals to the column name the window input exposes when it cancels the inner virtual model, and leaves them unchanged when the model stays.

With ALIGN TO FIRST OBSERVATION, FROM partway through a month, or a positive WITH OFFSET, the month and year samplers rounded a row that comes earlier in its month than the grid's day and time up to the next bucket, and strides of several months or years counted their buckets from January or 1970 instead of the anchor; round() now returns the last bucket start at or before the value, counting strides from the anchor month or year.

When the refresh interval iterator yielded no interval, incremental refresh of a materialized view took the view's cached query factory, never returned or freed it and never advanced the watermark, leaving the view stuck in 'refreshing' and leaking memory; findRefreshIntervals() now treats such an iterator as no intervals, and insertAsSelect() frees the factory if it ever sees one.

With a negative WITH OFFSET, or a FROM on day 29 to 31, timestamp_floor_utc() put rows after the start of a bucket on the last day of a shorter month into the previous bucket, which failed incremental refresh with "timestamp out of replace range" and invalidated the view; floorMM() and floorYYYY() with an offset now compare the value with the actual bucket start.

A fill list that mixes LINEAR with other values assumed equal bucket lengths and advanced the interpolation on every read of the column, so month strides, LIMIT, an outer WHERE, or reading the column twice produced wrong values; the fill cursor now passes the start of each gap bucket to the interpolation, and the results match FILL(LINEAR) alone.

Month and year floors with an offset or FROM now cost less per row, SAMPLE BY ... FILL(LINEAR) with a stride that divides a year runs within about 4% of before, strides that do not divide a year cost 3-6 ns more per row, and keyed SAMPLE BY 1M FROM ... FILL(LINEAR) runs 1.5-2% slower. Results change for the affected queries: window queries that select a column under several names and failed with Invalid column now compile, SELECT a, a AS b, row_number() OVER (ORDER BY a) over a table with a column b now sorts by a, strides that do not divide a year such as 5M now start their buckets on the same months on the SAMPLE BY cursor as on the GROUP BY path, and materialized views with a month or year stride and an offset may hold rows in wrong buckets from before the fix, which REFRESH MATERIALIZED VIEW ... FULL rewrites.

Timer refreshes with EVERY nM or EVERY ny follow the corrected grid, so a timer re-created partway through a period no longer skips a firing and multi-month cadences count from START rather than from January.

After a base table column changed type, for example from TIMESTAMP to SYMBOL, a full refresh of a materialized view that reads the column filled it with wrong values, such as timestamps in the year 56663, and still reported the view as valid, because the refresh job recompiled the view query but kept the row copier generated for the old result types while the view table's own metadata version had not changed.

With this fix MatViewRefreshJob generates a new copier whenever it recompiles the query and checks every result column against its view column with RecordToRowCopierUtils.isCopierConvertible(), so a result type that the copiers cannot convert invalidates the view with an error that names both columns.

isCopierConvertible() follows the INSERT INTO ... SELECT rule with two differences: it accepts DOUBLE into DATE and TIMESTAMP, which the copiers convert, so a view whose base column changed from TIMESTAMP to DOUBLE keeps refreshing, and it rejects numeric and temporal values into CHAR, for which the copiers write nothing.

The row copiers did not implement the SYMBOL to TIMESTAMP conversion although the type check admits it; they now parse the symbol text with the target column's timestamp driver, for microsecond and nanosecond columns, in INSERT INTO ... SELECT as well as in view refresh, with errors for malformed text naming SYMBOL as the source type.

As a behaviour change, a view whose recompiled query yields a type the copiers cannot convert now becomes invalid on refresh instead of refreshing with wrong values, including a base column changed from BOOLEAN to BYTE, and such views need to be recreated. A known limitation remains: a numeric value copied into a DATE or TIMESTAMP view column keeps its raw value in the view column's unit, so after a chain of type changes that alters the base column's unit the view refreshes as valid with values off by a factor of 1,000.

All three issues shared a single cause: an operator held a cursor or a raw address into an OrderedMap across a call that could grow the map and move its heap, then read freed memory. Depending on the contents of the freed memory, queries returned wrong rows, failed with InternalError: a fault occurred in an unsafe memory access operation, or crashed the JVM; the problem surfaced once a map outgrew its page, which with the default 32 KB page takes on the order of a thousand keys.

For RIGHT and FULL hash joins, the build map cursor was taken immediately after the build, while the probe phase could grow the map, so the scan over unmatched build rows walked the stale heap and reported matched rows as unmatched or crashed on garbage chain offsets; this fix takes the cursor when the unmatched-row scan starts and drops it on toTop().

For SPLICE JOIN, the cursor cached value addresses of the current master and slave keys that could be invalidated by the other side's createValue(), so it now caches the row ids it needs immediately after createValue(). For keyed SAMPLE BY FILL, the keys cursor was taken after the key discovery pass even though the second pass could grow the map, producing repeated or garbage key values in fill rows, so every fill scan now takes a fresh cursor.

Converting a split active WAL partition to Parquet could leave the replaced native column mappings open, causing later schema changes to fail. With this fix, native-to-Parquet conversion identifies the active partition by logical timestamp because it compacts all split siblings, while Parquet-to-native conversion retains exact physical matching because a mixed-format logical partition can still have an active native tail.

Queries running during out-of-order ingestion no longer return changed rows or boundary errors, and materialized view refreshes no longer become invalid under the same conditions. Late rows arriving before an added column's data no longer null out its values in running queries, and ALTER TABLE SQUASH PARTITIONS no longer loses rows when FORCE DROP PARTITION left a day's split partitions behind.

Split partitions now squash sooner, since a query started just before the target partition was written no longer delays squashing. In ADAPTIVE commit mode, crash recovery no longer restores corrupt rows after a partition split, because a save point taken before the split now protects the rows it needs in the same way an open query does.

As a tradeoff, while a query older than a split is open, late rows at the split partition's last timestamp cause the partition to be re-split or copied. These problems were introduced after the 10.1.0 release, so previously released versions are not affected.

A covering index (INDEX TYPE POSTING INCLUDE (...)) stores the values of the columns it includes in sidecar files, and the reader builds the sidecar name from the covered column's current name transaction; when the file was missing, every covered value of the partition was returned as NULL, including the designated timestamp.

This fix addresses several paths that left those files missing or wrong. A snapshot or backup restore that rebuilds indexes previously pointed the covering seal at the covered columns' native files, which Parquet partitions do not have, so a covering POSTING index on a Parquet partition is now rebuilt in its own pass that decodes the covered columns from the Parquet file.

RENAME and DROP INDEX on a covered column now hard-link the affected sidecars under the new name transaction in every partition, native and Parquet, with the old names retained for readers of earlier transactions until the seal purge removes them. UPDATE of a covered column now also rebuilds each POSTING index that includes an updated column in every updated partition, moving the index's own column to a new name transaction and queueing the old version for purge, so readers of earlier transactions keep the old index.

Finally, when the chain published covered bytes for a slot but the sidecar file is missing, the reader now throws covering index data is missing, rebuild the index or use the no_covering hint instead of silently returning NULLs; a partition left without its sidecars by an older version therefore fails covering queries until a write to the partition reseals the index, the index is rebuilt, or the query uses /*+ no_covering */.

An index already rebuilt by a restore over Parquet partitions keeps returning NULLs until it is rebuilt with DROP INDEX followed by ADD INDEX, since REINDEX skips Parquet partitions.

This fix also corrects Parquet conversion of a split last partition, where the last-partition check ran before split siblings were squashed and left the writer's columns open on the replaced native directory, later causing writer invariant violated: columns[] partially open during ALTER COLUMN TYPE.

As tradeoffs, renamed or index-dropped covered columns keep old-named sidecar hard links until the seal is superseded, RENAME and DROP INDEX scan each partition directory once per covering index that includes the column, and a restore decodes a Parquet partition once per covering index on it.

WAL apply no longer pauses when partition compaction holds the table writer, and such collisions no longer emit a misleading CRITICAL unsolicited table lock log message.

This fix changes symbol indexes on Parquet partitions to store index rows rather than partition rows, so that an out-of-order commit updating a Parquet partition in place no longer makes cursors opened before the commit read old-layout rows at new-layout row ids, which previously caused index scans to return rows of other keys, miss matching rows, or return nothing at all for POSTING indexes.

The _pm footer may now carry an index row map recording the first index row of every row group and the number of index rows the indexes cover; update_parquet_metadata keeps the block, bloom filters and index rows of unchanged row groups, while rewritten row groups take fresh index rows past the committed count, and index updates only append rows for new row groups.

Readers map rows through the footer, splitting a mapped partition into per-row-group frames, and every full index build over a Parquet file adds index rows in index row order. A footer without the map means identity, so older footers stay readable and no migration is required; however, once an update moves row groups to fresh index rows, an older binary will reject that partition's footer, index entries of replaced row groups remain until a rewrite or compaction rebuilds the index, and SELECT DISTINCT over a POSTING index becomes slower after scattered late writes until the day is compacted or rewritten.

This fix also stops recordAt() from reading a recycled Parquet decode buffer by bumping the bind generation when buffers are acquired or evicted, and preserves column tops across conversions: Parquet to native conversion now publishes skipped leading rows as the column top and writes NULL rows for later empty row groups, in-place out-of-order updates only append to an index under a committed top of 0 and otherwise rebuild it in full, and CONVERT TO NATIVE rebuilds rather than links an index under a nonzero top so IS NULL no longer returns top rows twice.

Storage-policy conversion moves from the writer to the partition compaction scan job, which writes a whole logical partition into a single Parquet file in one pass and can build a Parquet copy of a native partition off a reader before installing it, including for non-WAL tables, refusing a swap when the open transaction or a squash could invalidate it.

CONVERT PARTITION TO PARQUET likewise converts a non-active logical partition straight into one Parquet file instead of folding it first, with frame conversion writing an absent column as nulls with column top 0. Partitions written by QuestDB 9.3.4 to 10.0.1 may carry stale column tops whose indexes do not cover the data; index queries on such partitions now fail with index does not cover parquet partition data, partition compaction rebuilds it instead of returning wrong rows, and the compaction job rebuilds their indexes from row 0 and zeroes the stale tops.

Finally, conversions flush the Parquet file, footer and partition directory under the table's commit mode, swaps flush renamed and table directories before the transaction file under SYNC, and index files built by a conversion or compaction are flushed like regular column files, while an out-of-order merge removes pre-existing index files in its new partition directory before writing them.

When a WAL table had a backlog of small out-of-order transactions spanning a wide timestamp range, WAL apply built a block that its radix sort could not index: the sort packs the timestamp offset and the transaction index into one 64-bit key and fails once both need more than 8 bytes, for example more than 256 transactions spanning about 8.9 years in microseconds or about 3.3 days in nanoseconds.

The writer then applied transactions one by one and could fall behind ingestion indefinitely. This fix makes WalTxnDetails.calculateInsertTransactionBlock() track the minimum and maximum timestamp of the whole candidate block and stop extending it before the timestamp range plus transaction count overflows the sort key, using the table's native timestamp unit so that nanosecond tables are capped at a 1000x narrower time spread; blocks that would have overflowed are split into smaller blocks instead of being applied one by one, and the cap does not apply to blocks applied without the sort, that is non-dedup blocks of in-order, non-overlapping transactions from a single WAL segment.

This fix also corrects WAL apply block sizing on Parquet tables, where a Parquet last partition has no native column files so the average record size was never measured and blocks were sized from an estimate counting each variable-size column as 28 bytes, making blocks hundreds of times too long on wide rows.

Until the column files have been measured, WAL apply now measures bytes per row itself, sampling the WAL segment of the first pending transaction before the first block and measuring the staged rows after each apply.

This fix corrects several unrelated sources of wrong results and internal errors. On vectorized WINDOW JOIN plans, SUM() over a LONG256 column returned 0x00 or random values because the group by column sink had no LONG256 case and the batch sum read uninitialized memory; the sink now copies LONG256 values.

UNION, UNION ALL, INTERSECT and EXCEPT over geohash columns of the same storage width but different precision, such as GEOHASH(2c) and GEOHASH(3c), kept the trailing bits of the finer value instead of its leading bits and so returned the wrong cell and matched the wrong rows; the value is now narrowed with an explicit geohash cast, as was already done for differing storage widths.

SAMPLE BY with FILL(NULL) under ALIGN TO FIRST OBSERVATION, with a FROM expression, or in a mixed fill such as FILL(NULL, 0) failed with Unsupported type for aggregates returning DATE, STRING, VARCHAR, SYMBOL or LONG256, which now have NULL placeholders, while BOOLEAN and CHAR remain unsupported.

length_bytes(), starts_with(), strpos(), nullif(), replace(), json_extract() and arg_max() failed with an empty internal error on an IPv4 argument, and length_bytes() on a SYMBOL: IPv4 is now cast to VARCHAR when the argument matches a VARCHAR parameter, and symbol functions report the UTF-8 size of the symbol.

An empty IPv4 field over the UDP line protocol stored NULL and then also appended two bytes to the column, shifting every later value, which is now avoided.

Additionally, array bind variables accept NULL text as a NULL array, the generated record sink declares a larger stack for its chunked copy method so queries with around 600 or more GROUP BY key columns and a computed UUID or LONG128 key no longer fail, and the record-to-row copier now counts conversion code for geohash precision and timestamp unit changes so very wide INSERT ... SELECT statements with such conversions no longer exceed the generated method size limit.

This fix makes ALTER COLUMN TYPE preserve indexed results when decoding Parquet partitions, and prevents later Parquet conversions from suspending WAL tables after out-of-order writes.

This fix addresses an overflow in InterpolationUtil.interpolate(), which multiplied each value by a time distance in microseconds or nanoseconds before dividing. From about 2.5E298 with hourly buckets, and lower for wider buckets, longer gaps or nanosecond timestamps, the product overflowed to infinity, which reads as NULL.

The method now keeps the original formula whenever its result is finite, so ordinary results are unchanged, and otherwise recomputes the value from the two weights, which lie between 0 and 1 between two buckets with data. Buckets that a keyed FILL(LINEAR) extrapolates before a key's first row or after its last can still read NULL for large values, as before, and the farther the bucket lies from those rows, the lower the value at which this starts.

This fix ensures checkpoints preserve altered regular views despite WAL apply lag or a concurrent ALTER VIEW. Comparing the captured view definition with the live transaction file could skip the checkpoint transaction file when WAL apply lagged or another ALTER intervened, so QuestDB now builds an empty transaction file at the captured definition's sequencer transaction, making both describe the same view state.

HTTP cookie expiry handling also no longer depends on request timing, while strict expiry and session-count checks are retained.

QuestDB 9.3.4 to 10.0.1 could leave stale column tops after merging out-of-order Parquet rows. This fix lets affected Parquet indexes be repaired online with ALTER TABLE ... FORCE REINDEX PARQUET, while ADD INDEX and out-of-order writes repair affected local Parquet partitions automatically. The repair normalizes the affected metadata and rebuilds indexes in replacement directories while preserving active readers.

FORCE REINDEX supports column and partition selection, runs outside the WAL, and commits each partition separately, ADD INDEX includes repairs in its own transaction, and out-of-order writes rewrite affected partitions. Repairs fail on busy writers, retain completed partitions after cancellation, and skip cold and soft-linked partitions.

Parquet deduplication now matches merged Parquet keys using decoded row-group values instead of stale partition-level column tops, so duplicates are no longer retained, and VACUUM reclaims dropped posting-index files by discovering retired bitmap and posting files independently of the current index type.

This fix resolves concurrent parallel filter queries hanging PostgreSQL Wire Protocol or HTTP workers at full CPU. A query that helped reduce another query's frame could suspend while holding it, and queries queued behind that frame retried their collect without yielding the worker, so the suspended query never got a worker back.

PageFrameSequence.next() now parks the owner when a dispatch round publishes no new frame, and where there is no shared query pool fiber dispatcher to park on, the owner yields its worker instead, as do the other owner waits of parallel filter, GROUP BY, top-K and LATEST BY queries. Parallel filters with a bind variable also no longer skip rows in batched PostgreSQL Wire Protocol fetches: resuming a suspended portal rewrote the connection's bind variables while workers were still reducing its dispatched frames, so the execution context now tracks the page frame sequences of its open cursors and waits for their dispatched frames before rewriting bind variables.

Every wait in parallel query execution now wakes on the event it waits for through per-ring and per-query wait queues, with the timer only checking for timeouts, cancellation and disconnected clients, removing stalls of up to a second from missed wake-ups.

Additionally, SeqTxnTracker.initTxns() wakes wait_wal_table() waiters after a WAL notification queue overflow, and SqlTimeoutException clears its reused instance so repeated timeouts on one connection no longer return concatenated error messages.

This fix addresses a replica that could serve a live view with no rows forever if it restarted while the view's base table was still being downloaded. The restart cancelled the base table download and dropped the pending retry for the view, and the boot-time retry ran before the base table existed, so nothing re-attempted registration afterwards.

Live view registration is now retried once the base table arrives, and recovery publication, rollback and replicated drops are generation-aware so a recovered view can no longer displace or remove a same-name replacement.

A temporary object store transport error, such as an Azure Blob timeout or HTTP 504, during the upload of a backup partition data part was treated as an unknown write outcome and aborted the whole backup without using its retry budget. Because backup partition data is immutable and written to a unique key, these uploads are now retried with the existing bounded backoff and cancellation handling.

Permanent errors such as TLS failures still fail immediately, and cold storage, WAL and backup control uploads keep their conservative single-attempt behavior.

Previously SWITCH COLD STORAGE ROLE TO MANAGER returned HTTP 500 when another instance already held the manager lock, the Web Console reported the instance as unreachable, and the server logged an unhandled exception even though lock contention is an expected refusal. Routine refusals now return HTTP 400 with an actionable message that names the instance holding the lock and the recovery path, without incrementing the unhandled-error metric.

Promotion failures now return their concrete reason to the query, demotion no longer gets permanently stuck when the drain deadline passes or an ownership read fails, and only transitions with a genuinely unresolved remote mutation remain fenced.

ALTER USER and ALTER SERVICE ACCOUNT ... CREATE TOKEN returned zero rows on every execution of a cached plan after the first, while still creating the credential, leaving a live token that nobody could read or revoke individually. The same cached plans also skipped the permission check on reuse.

This fix rewinds the result cursor and re-runs authorization on every execution for REST tokens and JWK tokens, including CREATE TOKEN TYPE JWK WITH PUBLIC KEY.

The ACL cleanup after DROP TABLE and ALTER TABLE ... DROP COLUMN wrote revokes for every permission at the dropped scope rather than only the permissions stored there. After a restart replayed the ACL, those revokes shadowed database-level grants, so the entity silently lost the permission at database level and tables created afterwards no longer inherited it.

Cleanup now revokes only the permissions actually stored at the dropped scope and clears leftover grant options without revoking wider permissions.

This fix extends the retry handling for immutable backup uploads to each partition's metadata file. Previously a transient transport error on that upload was treated as an unknown outcome and aborted the whole backup, even though replication uploads to the same bucket recovered from the same error.

Partition metadata is written once per backup to a unique key, so it is now safely retried with the same bounded backoff, while manifests and other control objects keep the conservative path.

When a dropped table's local directory outlived its removal from the replication index, restarting the primary could treat it as a new table and retry uploading it from transaction zero even though its WAL segments had been purged. Retired tables are now recognized at startup, on hot promote and during later WAL events, their remaining upload pins are released, and stale index updates that would recreate them are rejected.

Tables dropped before their first upload still upload their history to preserve point-in-time recovery.

S3 closes idle connections after about 6 seconds, while the object store HTTP client kept them for 90 seconds, so reusing a connection just as S3 closed it failed the request with connection closed before message completed. The upload was retried without data loss, but each failure logged an error and could trip the elevated replication upload failure rate alert several times an hour.

Idle connections are now dropped after 4 seconds for all object store traffic, including replication, backup and cold storage.

Since 3.0.1, every routine TLS disconnect, such as a pooled QWP sender closing over wss, was logged as an ERROR on the server because the check that downgrades these messages matched outdated error text. The TLS layer now classifies end-of-file, connection reset, aborted connections and broken pipes by error kind and logs them at INFO. The downgrade for browsers that reject a self-signed certificate is fixed the same way.

A promote could reload the access list while a WAL apply worker was still applying recent ACL changes, such as a newly created user. The reload skipped the busy table without waiting, so the promoted instance came up without those users or groups and later statements failed with Entity does not exist.

Promote now waits for outstanding ACL WAL transactions to be applied before reloading the access list.

A cold storage decode could return a ready result even though its query had already been cancelled, when download completion was registered before the cancellation. Cancellation is now checked against both bound cancellation signals after re-polling, on completion and timer resume, and before falling back to a blocking wait, so cancelled queries stop promptly and release their resources.

Selective equality predicates were not derived for the grouped child scan of a join when the value involved a cast, bind variable, arithmetic expression or runtime-constant function, so QuestDB scanned and grouped an entire table before joining it to a single selected row, and the missing predicate also prevented Bloom filter and row-group statistics pruning on Parquet partitions.

This fix recognizes literals, bind variables, casts, arithmetic over constants and registered runtime-constant functions as effectively constant when the other equality operand is a single column, and derives equivalent filters across eligible equi-joins in a type-independent way, while keeping volatile expressions out of transitive propagation.

It also corrects incorrect pushdown of single-table ON predicates in queries with multiple LEFT, RIGHT or FULL OUTER JOINs: predicate origin and referenced model are now tracked so an inner ON predicate cannot move below a nulling boundary, ordering dependencies prevent join reordering from crossing such boundaries, transitive facts are scoped by model and column with their provenance retained, and barrier-join ON regexes can no longer publish invalid column facts.

Separately, a filtered query compiled while a table held only native partitions retained its native scan configuration after the partitions were converted to Parquet; eligible filtered page-frame plans are now associated with the partition-table version and the Parquet pruning capability present at compilation, cached plans are invalidated and recompiled on a native/Parquet capability transition, and each TableReader snapshot caches a Parquet-presence flag so steady-state cursor opens do not scan the partition list.

Affected RIGHT and FULL join shapes now return correct rows, at the cost of some inputs scanning more rows where a derived filter can no longer be safely applied.

This fix addresses a race where a healthy live view on a QuestDB Enterprise replica could be durably invalidated while its base table was still catching up. The ahead guard in the live view refresh job previously compared the view's watermark against the cached in-memory sequencer head alone. On a replica, the downloader appends to the on-disk transaction log behind that cache and reconciles it only later, so the WAL apply job consumes new transactions straight from the file and the refresh legitimately advances the watermark past the stale cached head; the guard misread this transient catch-up as unrecoverable data loss.

The guard now compares the watermark against the maximum of the cached sequencer head and the base tracker's writerTxn, which covers the stale-cache window on a replica while remaining a no-op on a primary, where the cached head stays authoritative. Genuine data-loss cases still invalidate the view, and the invalidation log line now prints both heads (baseTableTxn for the cached head and baseWriterTxn for the applied one) so an operator can see which one drove the decision.

The fix narrows rather than fully closes the false-invalidation window: where writerTxn has been reset to -1, the guard falls back to the previous behaviour.

This fix ensures that a parallel GROUP BY or horizon join failing inside the shard-merge phase reports the actual cause instead of timeout, query aborted.

Previously, a per-query memory limit breach, an mmap failure and an IO error all produced the same misleading timeout message; such queries now report the real failure, for example query memory limit exceeded [workload=QUERY, limit=..., used=...]. The shard-merge and parallel long top K jobs run on detached workers that cannot throw to the owner thread and previously signalled failure through a bare flag, dropping the exception.

The post-aggregation circuit breaker now keeps the message, position, errno, error kind and the cancellation, interruption and out-of-memory flags alongside the flag they explain, so the owner rebuilds and rethrows the worker's exception verbatim, with reset() clearing the flag and the error together.

Errors arriving after the breaker has already tripped are dropped so that a spurious abort cannot mask the real reason, and resolution follows a precedence order of the query's own circuit breaker, then the worker's recorded error, then the previous fallback. The asynchronous horizon join cursors publish through the same queue and receive the same treatment.

As a result, cancelling a query during the merge phase now reports cancelled by user rather than timeout, query aborted, so tooling matching on the old text will see a different string.

This fix resolves a defect where covered queries returned correct row IDs but NULL or empty covered payloads. The posting index writer keeps lazily-created read-only memory mappings of the covered source columns, and its lazy initializer early-returns whenever the arrays are non-null. A full seal with name-based covers maps one column at a time to bound peak memory, and the per-column unmap zeroed the array entries while leaving the arrays allocated.

From that point the initializer early-returned on stale arrays, every covered read resolved to a zero address, and the covered-value writers silently wrote the NULL sentinel. This affected both a post-seal generation flush on commit and an incremental seal, which re-reads covered values for every key of a dirty stride and therefore rewrote previously correct values as NULL.

The name-based per-column seal loops now reset the lazy mapping state when they finish, normally or exceptionally, so the next covered read lazily re-maps; the one-column-at-a-time memory bound is preserved at the cost of one open, mmap and close per covered column per seal-to-flush transition. The address-based O3 path was unaffected.

The bug shipped in 9.4.0 and later, and sidecar files written by affected versions may contain persisted NULL covered payloads, so tables using INDEX TYPE POSTING INCLUDE(...) built under those versions should have their index recreated.

This fix adds two generation-aware primitives to the live view registry, mirroring the compare-and-swap discipline already applied to table tokens: registerViewIfAbsent(instance) performs a put-if-absent style publication that refuses to displace an existing same-name entry and reports the current owner instead, and removeView(name, expected) performs an expected-value removal that atomically no-ops when another generation owns the name and takes the owner's fan-out entry with it only when it does own it.

Both update the name map and the base-table fan-out under the same per-base write lock, preserving the registry's torn-read contract. The registry is name-keyed with silent put and remove semantics, so a recovery path publishing a recovered live view without holding the table-name lock could, when stalled across a completed replicated DROP plus a same-name CREATE, displace the healthy replacement's registry entry, after which the recovery's own rollback removed it.

The replacement then stayed token-published but unregistered, absent from live_views(), skipped by the idle refresh scan and with its SELECT silently served from disk as empty until a restart, while the displaced instance's native state leaked. The new primitives make cross-generation displacement structurally impossible at the registry level; the change is purely additive and the existing registerView and removeView methods are untouched.

This fix preserves the rebase markers when a dropped table directory is cleaned up. The WAL apply job's dropped-table sweep deleted every plain file in the directory except _txn, _meta and the WAL locks, including the _rebase_source marker that the QuestDB Enterprise uploader relies on to record the old directory as a rebase source rather than a drop, which would otherwise wipe the table on the replica.

The two paths meet when ALTER TABLE ... REBASE WAL cannot tombstone the directory itself, since its removal of _txn and _meta is best-effort and loses to open handles on Windows; the directory then still looks like a table, the WAL purge job pings the apply job, and the drop lands on the next boot before the uploader reads the marker.

The sweep now skips _rebase_new and _rebase_source, matched by their shared _rebase_ prefix. Skipping only those entries is deliberate: the sweep still removes _txn and _meta so the directory stops looking like a table and can be reclaimed, avoiding an endless ping-pong between the two jobs and a leaked directory, and the WAL purge job still deletes the marker along with the rest of the directory.

This fix addresses a set of defects in the JIT filter compiler, which is enabled by default and therefore reachable from ordinary SQL. UUID range predicates no longer crash the process: UUID and LONG128 ordering is now declined by the serializer and answered by the Java filter, while equality and inequality remain compiled.

IPv4 and CHAR ordering are lowered into existing comparison, equality and boolean operations that implement unsigned order and correct NULL semantics, so these predicates stay JIT-compiled and vectorized, including quoted IPv4 literals; against a quoted literal the expansion collapses to a shorter form.

Negative SYMBOL literals such as WHERE sy = -5 now carry their sign through symbol-key resolution. BOOLEAN comparisons nested inside comparisons return correct rows, as the vectorized backend now harmonises comparison masks with raw boolean bytes and the AND/OR operations write to fresh registers instead of clobbering an operand that the rest of the predicate still reads.

A comparison that reaches no column no longer inherits an unrelated column's type, repeated reads of one column are cached per loop body, bind-variable broadcasts are cached, an out-of-bounds constant-pool read in the scalar backend is corrected, and IPv4 or CHAR predicates carrying arithmetic or a unary minus now run on the Java filter instead of compiling with incorrect semantics.

On the storage side, a covering POSTING index no longer returns NULL or 0 for blocks whose values all equal the column type's maximum, covering-index sidecar block sizes are computed in long to avoid an int overflow, and a designated TIMESTAMP_NS column now rejects values beyond 2261-12-31 23:59:59.999999999 instead of corrupting partition bookkeeping; Influx Line Protocol, QuestDB Wire Protocol and CSV import paths report such values as per-message or per-row errors that follow the configured ON ERROR or atomicity policy instead of distressing the writer, and a seeding live view that repeatedly faults on such a row now spends its retry budget and invalidates rather than retrying forever.

An existing table that already holds out-of-range rows is not repaired, and rewriting such a row through INSERT INTO ... SELECT or CREATE TABLE ... AS SELECT now fails with the bound's message.

This fix restores scheduling for materialized views that stopped being refreshed while every diagnostic surface reported them as healthy. ALTER MATERIALIZED VIEW ... SET REFRESH on an immediate, non-period view now registers timers unconditionally, instead of skipping registration because there was nothing to remove; previously such a view persisted refresh_type = 'timer' and reported view_status = 'valid' while nothing scheduled it, and the missing refresh-intervals timer also pinned the base table's WAL segments so they accumulated on disk.

The refresh job no longer drains its queue without bound: it yields after 32 tasks or a one-second elapsed-time budget, whichever comes first, so the timer job sharing the same workers is no longer starved by a base table that commits faster than its views refresh. Timers polled during a tick are now re-scheduled from a finally block, with each timer re-added under its own guard, so a throw mid-tick no longer permanently drops the rest of the batch.

Timer registration now takes its definition from a live view state, so an ALTER racing a DROP cannot recreate timers for a dropped view, and an expired timer whose state is missing or dropped is discarded rather than rearmed; invalid and pending-invalidation views keep their timers because they can recover.

For visibility, materialized_views() gains a trailing INT column timers_registered reporting how many timers the timer job currently holds for the view — zero is expected only for immediate, non-period views — the state store logs the refresh requests it drops, the timer job reports at ERROR when the gap between ticks exceeds a minute, and a timer whose firing schedules nothing three times in a row is reported once, with a matching line when it recovers.

Anything consuming SELECT * from materialized_views() positionally by width will see the extra column.

This fix corrects a case where a covering index returned wrong values for rows that existed before the indexed column was added: querying SELECT val FROM t WHERE sym IS NULL after adding sym and an index such as ALTER TABLE t ALTER COLUMN sym ADD INDEX TYPE POSTING INCLUDE (val) returned NULL for val, or dropped rows entirely when a whole partition predated the column.

Because such rows have no index entry, the planner now also compiles the ordinary non-covering index scan as a backup whenever the key can be NULL, and each time the query opens it checks whether any partition it is about to read is missing values for the column, falling back to the backup plan if so.

The trade-off is that a covering query whose key can be NULL gives up its page-frame cursor and runs serially, losing parallel filtering, parallel and vectorized GROUP BY, and parallel ASOF and window joins; the new /*+ force_use_covering */ hint buys that back where the scanned partitions are known to have no rows predating the column, and is verified rather than trusted, raising an error instead of returning wrong rows.

The check only considers partitions admitted by the query's time filter and compares the column's add time against the start of the first partition read. The same change also fixes incorrect included STRING, VARCHAR, BINARY and ARRAY values on time-bounded POSTING covering index queries that skipped delta blocks, LATEST ON returning nothing for a bind variable bound to NULL on an indexed column, a pooled reader keeping a stand-in index reader after an out-of-order insert so that the NULL key matched every row, and SAMPLE BY with first/last over a POSTING index throwing an error.

The cairo.wal.writer.madvise.mode values are now documented in server.conf, including the restart requirement.

This fix makes Influx Line Protocol over HTTP authorize each insert as the identity of the request that carries it. Although the HTTP layer derives a fresh security context per request, the per-table write object cached per TCP connection captured a security context once when it was created and discarded the one passed on every later cache hit.

Since the commit-time check is the only INSERT check on this path, whichever authenticated identity wrote to a table first on a keep-alive connection became the identity checked for every subsequent commit to that table on that connection, letting a less privileged identity inherit the first identity's INSERT permission.

Realistic ways for two identities to share a connection include proxies and load balancers with upstream keep-alive pooling, multi-tenant gateways, and clients that deliberately downgrade to a restricted token mid-connection; the exposure was bounded to INSERT into tables already written on that connection, as the live identity was still checked for the HTTP permission, entity enablement, CREATE TABLE and ADD COLUMN.

The cache now rebinds the security context on every hit, which is safe because rows are committed when the request completes and anything left over is rolled back before the next request starts. Influx Line Protocol over TCP and the QuestDB Wire Protocol were not affected, as both bind one identity per connection.

This fix prevents a transient reader-pool exhaustion from permanently invalidating a materialized view. The SQL optimiser wraps reader-acquisition failures in a SqlException, so the refresh job missed its existing retry path and treated the failure as a permanent compilation error; this affected both initial compilation and retries of cached queries, where a cached refresh could defer its first execution failure, discard the factory, and then invalidate the view when the next attempt recompiled against the still-full pool.

Wrapped pool-acquisition failures now carry a typed flag that the refresh job propagates through rollback and resource cleanup into the timer-driven retry path, while preserving the exception type, error code, position and message that ordinary SQL callers receive; the flag is cleared when the exception flyweight starts a new error so a later SQL error cannot inherit retryability.

The view can therefore catch up once readers become available without a new base-table commit or a manual refresh. The existing retry timeout and attempt limit are unchanged at 1 second and 10 retries, so prolonged contention can still invalidate the view, and ordinary HTTP queries are not switched into request retries.

This fix allows LAG() and LEAD() to return the neighbouring row's symbol, with or without PARTITION BY, ORDER BY and IGNORE NULLS, and the result behaves like any other symbol column in filters, joins, GROUP BY and ORDER BY. Nested usage such as LAG(p) over p = LAG(v::symbol) now returns correct values.

Along the way the fix corrects several related issues: SYMBOL equality now treats NULL as equal to NULL everywhere (so = may return more rows and != fewer), comparing a symbol with a string no longer matches every row when both sides read the same dictionary, BOOLEAN-to-SYMBOL FIRST(), LAST() and MODE() return NULL rather than false for empty groups, equality on NOCACHE SYMBOL columns returns correct results for hash-colliding values, and window queries using PARTITION BY with a STRING-to-SYMBOL cast now release their partition-expression state on cursor close.

TRIM(), LTRIM() and RTRIM() on STRING and SYMBOL values no longer return an empty string when the trimmed result is exactly one character, so WHERE trim(sym) = 'a' now matches. Sub-queries inside select-list expressions no longer disturb preceding columns, and window functions whose argument contains a sub-query now work with PARTITION BY.

Joins whose key combined a SYMBOL = SYMBOL pair with a SYMBOL = STRING or SYMBOL = VARCHAR pair no longer lose matches in hash, ASOF, LT, SPLICE and HORIZON joins, since each side of a join now owns its symbol-encoding flags. Finally, a RIGHT or FULL OUTER JOIN with a non-equality ON clause now runs before later INNER, CROSS, RIGHT and FULL OUTER joins instead of being reordered behind them, which previously produced wrong rows without an error.

Limitations: only a NULL default is supported, so lag(sym, 1, 'x') fails; SYMBOL LAG()/LEAD() are not supported in live views; STRING/VARCHAR arguments still require a ::symbol cast; first_value, last_value, max, min and nth_value over SYMBOL now fail at compile time with a clear error; a sub-query in a window PARTITION BY, ORDER BY or frame bound now fails with query is not allowed here; and because the non-equi outer join now runs first, a selective later INNER JOIN no longer shrinks its nested-loop input, so such queries can be slower.

This fix corrects invalid HTTP 206 partial responses that caused browsers to abandon resumed downloads and execute truncated files, which left the Web Console stuck on "Loading" with an Unexpected end of input error on slow connections. Byte ranges are now treated as inclusive on both ends, so bytes=0-0 returns a single byte and Content-Length matches end - start + 1; the Content-Range header now reports the last byte of the body rather than a value past the end of the file; the ETag is quoted on 206 responses and If-Range is honoured, falling back to a full 200 response when the validator is stale; and range bounds are validated properly, so a start at or beyond the file length and an inverted range return 416 with Content-Range: bytes */LENGTH, while an oversized end is clamped to the file length instead of being rejected. Suffix ranges and multiple ranges continue to return 416.

Sealing a posting index could crash QuestDB or write a broken index when one group of 256 symbol keys held more than roughly 573 million rows in a single partition, or more than 2 GB of compressed row IDs, which can occur with a SYMBOL column that has few distinct values in a very large partition.

An internal size calculation overflowed, causing the writer to pick a compact layout that did not fit its buffer. This fix calculates those sizes without overflow and falls back to the unbounded layout when the compact one would not fit. Indexes below these sizes keep the same on-disk layout, readers and query paths are unchanged so query speed is unaffected, and the writer only performs a few additional 64-bit additions per key when sealing; very large groups that previously overflowed now produce somewhat larger index files.

A QuestDB instance could stop serving requests entirely after an OutOfMemoryError, with every network worker blocked while waiting for a log ring slot. A log call claimed its ring slot at the start of the chain and published it only at the end, so any exception in between left a slot claimed but never published, which prevented the single log consumer from advancing and eventually blocked all producers.

This fix makes log records format into a fixed-size, on-heap staging sink and claim the ring slot only at publication time, so a failed, abandoned or thread-dead chain loses at most its own message and can no longer wedge the queue. The staging record is now one per carrier and shared by all loggers, abandoned or nested chains are detected by the next chain on the same carrier and published with an ABANDONED marker, and worker error reporting no longer throws: job names are materialized up front instead of calling toString() while logging an unhandled job error, and appenders that call foreign code publish the partial message and rethrow on failure.

As a consequence, with a full ring a non-waiting call now formats and then drops its message rather than becoming a no-op, waiting calls block at publication time instead of at the chain start, and lines from different threads can show slightly out-of-order timestamps since ordering follows publication time while timestamps come from the chain start.

For statements executed at parse time, such as TRUNCATE, RENAME TABLE, SET, BEGIN/COMMIT/ROLLBACK, REFRESH MATERIALIZED VIEW and access control statements, the server reported -1 affected rows to QWP clients, which some clients rejected or reported as an invalid count. These statements now report 0, as the protocol specification states. QWP senders also no longer time out when calling close().

This fix addresses three problems in parallel filtered queries. Queries that read two filtered table scans one after the other, such as a hash join whose build and probe sides both run as async filters or a UNION ALL of two filtered scans, could hang indefinitely when both scans landed on the same reduce shard and the second scan had more page frames than cairo.page.frame.reduce.queue.capacity; while stalled, every worker thread sat idle and only CANCEL QUERY or a statement timeout ended the query.

A page frame sequence now reduces locally whenever it is still active and has no frame of its own in flight, regardless of which runtime owns the current fiber, and a finished sequence suspends its collect subscription so it no longer gates the publisher, with toTop() resuming it before the sequence dispatches again.

This also removes the long-standing slowdown where frames of the second scan beyond queue capacity were filtered one at a time on the query thread instead of on the worker pool. Finally, a SELECT count() over a single-frame filtered scan, or a filtered window join, could return 0 instead of a cancellation or timeout error when the query was cancelled while that frame was being filtered; size calculation now re-checks that all frames were active after the loop.

SELECT t.k FROM t JOIN s ON s.k = t.k WHERE t.vt IS NULL AND s.ct = 'u';

A cursor that stops mid-way, for example a LIMIT inside a join's build side or a client that pauses fetching, still pins its shard, and sequences behind it fall back to reducing frame by frame on the query thread.

This fix restores diagnostics and offset counting for HORIZON JOIN. The JIT compiler could reuse an ArithmeticException without a message, causing a parallel HORIZON JOIN to report only unexpected reduce error; the checked addition used by the serial iterator is now also used during heap initialization and subsequent iteration, so a timestamp overflow consistently produces a non-critical exception carrying the timestamp and the offset.

For microsecond timestamps, RANGE FROM -9000000000000s TO 9000000000000s STEP 9000000000000s should produce three offsets but signed subtraction overflow previously reduced it to one; the span is now divided as an unsigned value and the configured limit is checked before adding one or narrowing the count, with counts beyond long reporting a truthful lower bound in the existing SQL limit error.

The timestamp helper still inlines and retains its intrinsic, and RANGE counting runs during query compilation so it adds no per-row work.

This fix addresses three problems with O3 merges into Parquet partitions after ALTER COLUMN TYPE. Previously, every O3 commit rewrote the entire Parquet file after a type change, because a column was treated as type-converted whenever its original writer index differed from its writer index; a column is now considered type-converted only when the type stored in the Parquet file also differs from the table's column type, so only the first merge after the ALTER rewrites the file and later merges take the in-place update path.

Second, an indexed SYMBOL column converted from another type kept a stale symbol index after an in-place O3 update, because the Parquet column lookup used the current writer index instead of the original one, causing indexed lookups to return rows that no longer matched the merged data. Third, after a VARCHAR -> STRING -> VARCHAR round trip the table writer moves the column to the end of its metadata while the Parquet file stays untouched, and the Rust Parquet updater encoded new and replaced row groups positionally against the file schema, writing values into the wrong columns or suspending the table; columns are now reordered to the file schema by Parquet field id when replacing or inserting row groups, with a clear error returned for unmatched or duplicate ids.

Additionally, horizon join timestamp overflow now reports a descriptive horizon timestamp overflow error instead of a bare internal reduce error.

This fix makes buffered log records visible promptly and lets the logging subsystem recover from failed rolls. The rolling file writer previously waited for 100,000 idle job passes before flushing, which could hold low-traffic records in memory for several minutes; it now flushes a non-empty buffer one millisecond after the latest buffered record, keeps the idle-pass count as a fallback, opens the active log path in append mode during startup, and reserves numbered-file creation for configured size or time roll events, so restarts no longer accumulate empty numbered files.

Failed rolls are now recoverable: the descriptor is reset immediately after the old file is closed, the roll deadline advances only after the new file opens, a flush always rolls when no file is open, and close() releases the buffer, descriptor and paths before rethrowing a flush error, so a failed rename, expired-log removal or open no longer stops file logging until restart or writes log text into an unrelated file.

In addition, only one log factory is now constructed per process: loggers requested during construction receive a deferred logger that is bound after initialisation, the logging worker pool starts without a logger so writer failures are reported on stderr instead of wedging the worker, and the writer rolls an existing file aside when an append open fails.

This halves the logging threads, configuration reads and native logger memory of a default server start, and a malformed log.conf now fails startup with a plain log error. A related overflow check was added to the zero-operand fast paths of Decimal128 and Decimal256 addition and subtraction, so checked operations never return an out-of-range value.

Concurrent PostgreSQL Wire Protocol queries could cause EXPLAIN CREATE TABLE ... AS SELECT and EXPLAIN CREATE MATERIALIZED VIEW to throw a NullPointerException when the compiler was reused before the plan was rendered, and could also produce incorrect table names or statement types in EXPLAIN INSERT and EXPLAIN UPDATE. This fix snapshots the table name and statement type information during compilation, so the EXPLAIN factory no longer retains a reusable execution model.

Large QWP reads could keep growing server scratch memory after a partial frame was sent, and on large enough results this crashed QuestDB. The server now sends the rest of a split batch before reading more rows, keeping memory bounded to one batch; in a 50-million-row read, peak server memory dropped from 6.40 GiB to 462 MiB.

Cancelling a query mid-stream no longer leaves unsent rows that the next query on the connection returned ahead of its own results, and a query failing mid-stream no longer breaks SYMBOL decoding for the next query.

This fix corrects two SAMPLE BY ... FILL defects. Previously the bucket column was located in the GROUP BY output by name, so any TIMESTAMP output column sharing the timestamp's name was mistaken for the bucket, causing assertion errors, unbounded fill rows, too many rows for queries such as SELECT first(ts) AS ts, avg(val) FROM t SAMPLE BY 1h FILL(NULL), or dropped gap rows for a qualified timestamp_floor('1d', t.ts) AS ts; the optimizer now records the bucket key node it creates and code generation resolves the bucket by that node regardless of alias.

Second, an outer GROUP BY over a fill sub-query, such as SELECT ts, count() FROM (SELECT ts, avg(val) v FROM t SAMPLE BY 1h FILL(NULL)) WHERE v > 1.5 GROUP BY ts, received a second fill that re-inserted filtered gap rows and corrupted aggregates; the fill is now applied only when the GROUP BY output itself carries the recorded bucket node, while still running for fills inside a LATERAL body.

As a result, a time-series operator over an outer GROUP BY ts on a fill sub-query without an ORDER BY now fails with left side of time series join has no timestamp unless ORDER BY ts is added, SELECT first(ts) AS ts, avg(val) FROM t SAMPLE BY 1h FILL(0) now reports Invalid fill value: '0'. Timestamp fill value must be in quotes, and a projection selecting both a qualified and unqualified timestamp copy consistently returns a keyed fill for either column order.

This fix addresses two symbol-map correctness issues. The symbol map reader removed the wrong cache range when the visible symbol count shrank and kept its maximum offset at the previous high-water mark, so a key lookup could return a key outside the current symbol count; the cache and the offset now shrink together with the visible symbol count.

WAL symbol diff keys were only required to be dense by an assertion, which production builds do not enforce, so an invalid or sparse diff could pass through silently; the keys are now validated at runtime and a sparse diff causes WAL apply to report the relevant transaction and symbol metadata and suspend the table instead of applying a potentially inconsistent mapping.

The validation adds one integer comparison per new symbol diff entry and no per-row work, and deliberately favours containment over continuing with an invalid mapping.

The segmented multi-producer multi-consumer concurrent queue froze a segment by publishing the frozen flag before bumping the tail, while the dequeue path read the flag before the tail. In the window between the two writes a consumer could pair a set flag with the pre-freeze tail and subtract the freeze offset from a tail that was never bumped, causing the queue to report empty while it still held committed items; the memory fence did not close the window, since the freezing thread can stall between the two writes.

This fix bumps the tail before publishing the flag, so a visible flag always implies a bumped tail and a clear flag with a bumped tail simply retries, adding no additional synchronization. The sized queue constructor, which asserted its size argument was a power of two and then ignored it while always allocating a 32-slot first segment, is also fixed.

Selective equality predicates were not derived for the grouped child scan of a join when the value involved a cast, bind variable, arithmetic expression or runtime-constant function, so QuestDB scanned and grouped an entire table before joining it to a single selected row, and the missing predicate also prevented Bloom filter and row-group statistics pruning on Parquet partitions.

This fix recognizes literals, bind variables, casts, arithmetic over constants and registered runtime-constant functions as effectively constant when the other equality operand is a single column, and derives equivalent filters across eligible equi-joins in a type-independent way, while keeping volatile expressions out of transitive propagation.

It also corrects incorrect pushdown of single-table ON predicates in queries with multiple LEFT, RIGHT or FULL OUTER JOINs: predicate origin and referenced model are now tracked so an inner ON predicate cannot move below a nulling boundary, ordering dependencies prevent join reordering from crossing such boundaries, transitive facts are scoped by model and column with their provenance retained, and barrier-join ON regexes can no longer publish invalid column facts.

Separately, a filtered query compiled while a table held only native partitions retained its native scan configuration after the partitions were converted to Parquet; eligible filtered page-frame plans are now associated with the partition-table version and the Parquet pruning capability present at compilation, cached plans are invalidated and recompiled on a native/Parquet capability transition, and each TableReader snapshot caches a Parquet-presence flag so steady-state cursor opens do not scan the partition list.

Affected RIGHT and FULL join shapes now return correct rows, at the cost of some inputs scanning more rows where a derived filter can no longer be safely applied.

This fix addresses a race where a healthy live view on a QuestDB Enterprise replica could be durably invalidated while its base table was still catching up. The ahead guard in the live view refresh job previously compared the view's watermark against the cached in-memory sequencer head alone. On a replica, the downloader appends to the on-disk transaction log behind that cache and reconciles it only later, so the WAL apply job consumes new transactions straight from the file and the refresh legitimately advances the watermark past the stale cached head; the guard misread this transient catch-up as unrecoverable data loss.

The guard now compares the watermark against the maximum of the cached sequencer head and the base tracker's writerTxn, which covers the stale-cache window on a replica while remaining a no-op on a primary, where the cached head stays authoritative. Genuine data-loss cases still invalidate the view, and the invalidation log line now prints both heads (baseTableTxn for the cached head and baseWriterTxn for the applied one) so an operator can see which one drove the decision.

The fix narrows rather than fully closes the false-invalidation window: where writerTxn has been reset to -1, the guard falls back to the previous behaviour.

This fix ensures that a parallel GROUP BY or horizon join failing inside the shard-merge phase reports the actual cause instead of timeout, query aborted.

Previously, a per-query memory limit breach, an mmap failure and an IO error all produced the same misleading timeout message; such queries now report the real failure, for example query memory limit exceeded [workload=QUERY, limit=..., used=...]. The shard-merge and parallel long top K jobs run on detached workers that cannot throw to the owner thread and previously signalled failure through a bare flag, dropping the exception.

The post-aggregation circuit breaker now keeps the message, position, errno, error kind and the cancellation, interruption and out-of-memory flags alongside the flag they explain, so the owner rebuilds and rethrows the worker's exception verbatim, with reset() clearing the flag and the error together.

Errors arriving after the breaker has already tripped are dropped so that a spurious abort cannot mask the real reason, and resolution follows a precedence order of the query's own circuit breaker, then the worker's recorded error, then the previous fallback. The asynchronous horizon join cursors publish through the same queue and receive the same treatment.

As a result, cancelling a query during the merge phase now reports cancelled by user rather than timeout, query aborted, so tooling matching on the old text will see a different string.

This fix resolves a defect where covered queries returned correct row IDs but NULL or empty covered payloads. The posting index writer keeps lazily-created read-only memory mappings of the covered source columns, and its lazy initializer early-returns whenever the arrays are non-null. A full seal with name-based covers maps one column at a time to bound peak memory, and the per-column unmap zeroed the array entries while leaving the arrays allocated.

From that point the initializer early-returned on stale arrays, every covered read resolved to a zero address, and the covered-value writers silently wrote the NULL sentinel. This affected both a post-seal generation flush on commit and an incremental seal, which re-reads covered values for every key of a dirty stride and therefore rewrote previously correct values as NULL.

The name-based per-column seal loops now reset the lazy mapping state when they finish, normally or exceptionally, so the next covered read lazily re-maps; the one-column-at-a-time memory bound is preserved at the cost of one open, mmap and close per covered column per seal-to-flush transition. The address-based O3 path was unaffected.

The bug shipped in 9.4.0 and later, and sidecar files written by affected versions may contain persisted NULL covered payloads, so tables using INDEX TYPE POSTING INCLUDE(...) built under those versions should have their index recreated.

This fix adds two generation-aware primitives to the live view registry, mirroring the compare-and-swap discipline already applied to table tokens: registerViewIfAbsent(instance) performs a put-if-absent style publication that refuses to displace an existing same-name entry and reports the current owner instead, and removeView(name, expected) performs an expected-value removal that atomically no-ops when another generation owns the name and takes the owner's fan-out entry with it only when it does own it.

Both update the name map and the base-table fan-out under the same per-base write lock, preserving the registry's torn-read contract. The registry is name-keyed with silent put and remove semantics, so a recovery path publishing a recovered live view without holding the table-name lock could, when stalled across a completed replicated DROP plus a same-name CREATE, displace the healthy replacement's registry entry, after which the recovery's own rollback removed it.

The replacement then stayed token-published but unregistered, absent from live_views(), skipped by the idle refresh scan and with its SELECT silently served from disk as empty until a restart, while the displaced instance's native state leaked. The new primitives make cross-generation displacement structurally impossible at the registry level; the change is purely additive and the existing registerView and removeView methods are untouched.

This fix preserves the rebase markers when a dropped table directory is cleaned up. The WAL apply job's dropped-table sweep deleted every plain file in the directory except _txn, _meta and the WAL locks, including the _rebase_source marker that the QuestDB Enterprise uploader relies on to record the old directory as a rebase source rather than a drop, which would otherwise wipe the table on the replica.

The two paths meet when ALTER TABLE ... REBASE WAL cannot tombstone the directory itself, since its removal of _txn and _meta is best-effort and loses to open handles on Windows; the directory then still looks like a table, the WAL purge job pings the apply job, and the drop lands on the next boot before the uploader reads the marker.

The sweep now skips _rebase_new and _rebase_source, matched by their shared _rebase_ prefix. Skipping only those entries is deliberate: the sweep still removes _txn and _meta so the directory stops looking like a table and can be reclaimed, avoiding an endless ping-pong between the two jobs and a leaked directory, and the WAL purge job still deletes the marker along with the rest of the directory.

This fix addresses a set of defects in the JIT filter compiler, which is enabled by default and therefore reachable from ordinary SQL. UUID range predicates no longer crash the process: UUID and LONG128 ordering is now declined by the serializer and answered by the Java filter, while equality and inequality remain compiled.

IPv4 and CHAR ordering are lowered into existing comparison, equality and boolean operations that implement unsigned order and correct NULL semantics, so these predicates stay JIT-compiled and vectorized, including quoted IPv4 literals; against a quoted literal the expansion collapses to a shorter form.

Negative SYMBOL literals such as WHERE sy = -5 now carry their sign through symbol-key resolution. BOOLEAN comparisons nested inside comparisons return correct rows, as the vectorized backend now harmonises comparison masks with raw boolean bytes and the AND/OR operations write to fresh registers instead of clobbering an operand that the rest of the predicate still reads.

A comparison that reaches no column no longer inherits an unrelated column's type, repeated reads of one column are cached per loop body, bind-variable broadcasts are cached, an out-of-bounds constant-pool read in the scalar backend is corrected, and IPv4 or CHAR predicates carrying arithmetic or a unary minus now run on the Java filter instead of compiling with incorrect semantics.

On the storage side, a covering POSTING index no longer returns NULL or 0 for blocks whose values all equal the column type's maximum, covering-index sidecar block sizes are computed in long to avoid an int overflow, and a designated TIMESTAMP_NS column now rejects values beyond 2261-12-31 23:59:59.999999999 instead of corrupting partition bookkeeping; Influx Line Protocol, QuestDB Wire Protocol and CSV import paths report such values as per-message or per-row errors that follow the configured ON ERROR or atomicity policy instead of distressing the writer, and a seeding live view that repeatedly faults on such a row now spends its retry budget and invalidates rather than retrying forever.

An existing table that already holds out-of-range rows is not repaired, and rewriting such a row through INSERT INTO ... SELECT or CREATE TABLE ... AS SELECT now fails with the bound's message.

This fix restores scheduling for materialized views that stopped being refreshed while every diagnostic surface reported them as healthy. ALTER MATERIALIZED VIEW ... SET REFRESH on an immediate, non-period view now registers timers unconditionally, instead of skipping registration because there was nothing to remove; previously such a view persisted refresh_type = 'timer' and reported view_status = 'valid' while nothing scheduled it, and the missing refresh-intervals timer also pinned the base table's WAL segments so they accumulated on disk.

The refresh job no longer drains its queue without bound: it yields after 32 tasks or a one-second elapsed-time budget, whichever comes first, so the timer job sharing the same workers is no longer starved by a base table that commits faster than its views refresh. Timers polled during a tick are now re-scheduled from a finally block, with each timer re-added under its own guard, so a throw mid-tick no longer permanently drops the rest of the batch.

Timer registration now takes its definition from a live view state, so an ALTER racing a DROP cannot recreate timers for a dropped view, and an expired timer whose state is missing or dropped is discarded rather than rearmed; invalid and pending-invalidation views keep their timers because they can recover.

For visibility, materialized_views() gains a trailing INT column timers_registered reporting how many timers the timer job currently holds for the view — zero is expected only for immediate, non-period views — the state store logs the refresh requests it drops, the timer job reports at ERROR when the gap between ticks exceeds a minute, and a timer whose firing schedules nothing three times in a row is reported once, with a matching line when it recovers.

Anything consuming SELECT * from materialized_views() positionally by width will see the extra column.

This fix corrects a case where a covering index returned wrong values for rows that existed before the indexed column was added: querying SELECT val FROM t WHERE sym IS NULL after adding sym and an index such as ALTER TABLE t ALTER COLUMN sym ADD INDEX TYPE POSTING INCLUDE (val) returned NULL for val, or dropped rows entirely when a whole partition predated the column.

Because such rows have no index entry, the planner now also compiles the ordinary non-covering index scan as a backup whenever the key can be NULL, and each time the query opens it checks whether any partition it is about to read is missing values for the column, falling back to the backup plan if so.

The trade-off is that a covering query whose key can be NULL gives up its page-frame cursor and runs serially, losing parallel filtering, parallel and vectorized GROUP BY, and parallel ASOF and window joins; the new /*+ force_use_covering */ hint buys that back where the scanned partitions are known to have no rows predating the column, and is verified rather than trusted, raising an error instead of returning wrong rows.

The check only considers partitions admitted by the query's time filter and compares the column's add time against the start of the first partition read. The same change also fixes incorrect included STRING, VARCHAR, BINARY and ARRAY values on time-bounded POSTING covering index queries that skipped delta blocks, LATEST ON returning nothing for a bind variable bound to NULL on an indexed column, a pooled reader keeping a stand-in index reader after an out-of-order insert so that the NULL key matched every row, and SAMPLE BY with first/last over a POSTING index throwing an error.

The cairo.wal.writer.madvise.mode values are now documented in server.conf, including the restart requirement.

This fix makes Influx Line Protocol over HTTP authorize each insert as the identity of the request that carries it. Although the HTTP layer derives a fresh security context per request, the per-table write object cached per TCP connection captured a security context once when it was created and discarded the one passed on every later cache hit.

Since the commit-time check is the only INSERT check on this path, whichever authenticated identity wrote to a table first on a keep-alive connection became the identity checked for every subsequent commit to that table on that connection, letting a less privileged identity inherit the first identity's INSERT permission.

Realistic ways for two identities to share a connection include proxies and load balancers with upstream keep-alive pooling, multi-tenant gateways, and clients that deliberately downgrade to a restricted token mid-connection; the exposure was bounded to INSERT into tables already written on that connection, as the live identity was still checked for the HTTP permission, entity enablement, CREATE TABLE and ADD COLUMN.

The cache now rebinds the security context on every hit, which is safe because rows are committed when the request completes and anything left over is rolled back before the next request starts. Influx Line Protocol over TCP and the QuestDB Wire Protocol were not affected, as both bind one identity per connection.

This fix prevents a transient reader-pool exhaustion from permanently invalidating a materialized view. The SQL optimiser wraps reader-acquisition failures in a SqlException, so the refresh job missed its existing retry path and treated the failure as a permanent compilation error; this affected both initial compilation and retries of cached queries, where a cached refresh could defer its first execution failure, discard the factory, and then invalidate the view when the next attempt recompiled against the still-full pool.

Wrapped pool-acquisition failures now carry a typed flag that the refresh job propagates through rollback and resource cleanup into the timer-driven retry path, while preserving the exception type, error code, position and message that ordinary SQL callers receive; the flag is cleared when the exception flyweight starts a new error so a later SQL error cannot inherit retryability.

The view can therefore catch up once readers become available without a new base-table commit or a manual refresh. The existing retry timeout and attempt limit are unchanged at 1 second and 10 retries, so prolonged contention can still invalidate the view, and ordinary HTTP queries are not switched into request retries.

This fix allows LAG() and LEAD() to return the neighbouring row's symbol, with or without PARTITION BY, ORDER BY and IGNORE NULLS, and the result behaves like any other symbol column in filters, joins, GROUP BY and ORDER BY. Nested usage such as LAG(p) over p = LAG(v::symbol) now returns correct values.

Along the way the fix corrects several related issues: SYMBOL equality now treats NULL as equal to NULL everywhere (so = may return more rows and != fewer), comparing a symbol with a string no longer matches every row when both sides read the same dictionary, BOOLEAN-to-SYMBOL FIRST(), LAST() and MODE() return NULL rather than false for empty groups, equality on NOCACHE SYMBOL columns returns correct results for hash-colliding values, and window queries using PARTITION BY with a STRING-to-SYMBOL cast now release their partition-expression state on cursor close.

TRIM(), LTRIM() and RTRIM() on STRING and SYMBOL values no longer return an empty string when the trimmed result is exactly one character, so WHERE trim(sym) = 'a' now matches. Sub-queries inside select-list expressions no longer disturb preceding columns, and window functions whose argument contains a sub-query now work with PARTITION BY.

Joins whose key combined a SYMBOL = SYMBOL pair with a SYMBOL = STRING or SYMBOL = VARCHAR pair no longer lose matches in hash, ASOF, LT, SPLICE and HORIZON joins, since each side of a join now owns its symbol-encoding flags. Finally, a RIGHT or FULL OUTER JOIN with a non-equality ON clause now runs before later INNER, CROSS, RIGHT and FULL OUTER joins instead of being reordered behind them, which previously produced wrong rows without an error.

Limitations: only a NULL default is supported, so lag(sym, 1, 'x') fails; SYMBOL LAG()/LEAD() are not supported in live views; STRING/VARCHAR arguments still require a ::symbol cast; first_value, last_value, max, min and nth_value over SYMBOL now fail at compile time with a clear error; a sub-query in a window PARTITION BY, ORDER BY or frame bound now fails with query is not allowed here; and because the non-equi outer join now runs first, a selective later INNER JOIN no longer shrinks its nested-loop input, so such queries can be slower.

This fix corrects invalid HTTP 206 partial responses that caused browsers to abandon resumed downloads and execute truncated files, which left the Web Console stuck on "Loading" with an Unexpected end of input error on slow connections. Byte ranges are now treated as inclusive on both ends, so bytes=0-0 returns a single byte and Content-Length matches end - start + 1; the Content-Range header now reports the last byte of the body rather than a value past the end of the file; the ETag is quoted on 206 responses and If-Range is honoured, falling back to a full 200 response when the validator is stale; and range bounds are validated properly, so a start at or beyond the file length and an inverted range return 416 with Content-Range: bytes */LENGTH, while an oversized end is clamped to the file length instead of being rejected. Suffix ranges and multiple ranges continue to return 416.

Sealing a posting index could crash QuestDB or write a broken index when one group of 256 symbol keys held more than roughly 573 million rows in a single partition, or more than 2 GB of compressed row IDs, which can occur with a SYMBOL column that has few distinct values in a very large partition.

An internal size calculation overflowed, causing the writer to pick a compact layout that did not fit its buffer. This fix calculates those sizes without overflow and falls back to the unbounded layout when the compact one would not fit. Indexes below these sizes keep the same on-disk layout, readers and query paths are unchanged so query speed is unaffected, and the writer only performs a few additional 64-bit additions per key when sealing; very large groups that previously overflowed now produce somewhat larger index files.

A QuestDB instance could stop serving requests entirely after an OutOfMemoryError, with every network worker blocked while waiting for a log ring slot. A log call claimed its ring slot at the start of the chain and published it only at the end, so any exception in between left a slot claimed but never published, which prevented the single log consumer from advancing and eventually blocked all producers.

This fix makes log records format into a fixed-size, on-heap staging sink and claim the ring slot only at publication time, so a failed, abandoned or thread-dead chain loses at most its own message and can no longer wedge the queue. The staging record is now one per carrier and shared by all loggers, abandoned or nested chains are detected by the next chain on the same carrier and published with an ABANDONED marker, and worker error reporting no longer throws: job names are materialized up front instead of calling toString() while logging an unhandled job error, and appenders that call foreign code publish the partial message and rethrow on failure.

As a consequence, with a full ring a non-waiting call now formats and then drops its message rather than becoming a no-op, waiting calls block at publication time instead of at the chain start, and lines from different threads can show slightly out-of-order timestamps since ordering follows publication time while timestamps come from the chain start.

This fix addresses three problems in parallel filtered queries. Queries that read two filtered table scans one after the other, such as a hash join whose build and probe sides both run as async filters or a UNION ALL of two filtered scans, could hang indefinitely when both scans landed on the same reduce shard and the second scan had more page frames than cairo.page.frame.reduce.queue.capacity; while stalled, every worker thread sat idle and only CANCEL QUERY or a statement timeout ended the query.

A page frame sequence now reduces locally whenever it is still active and has no frame of its own in flight, regardless of which runtime owns the current fiber, and a finished sequence suspends its collect subscription so it no longer gates the publisher, with toTop() resuming it before the sequence dispatches again.

This also removes the long-standing slowdown where frames of the second scan beyond queue capacity were filtered one at a time on the query thread instead of on the worker pool. Finally, a SELECT count() over a single-frame filtered scan, or a filtered window join, could return 0 instead of a cancellation or timeout error when the query was cancelled while that frame was being filtered; size calculation now re-checks that all frames were active after the loop.

SELECT t.k FROM t JOIN s ON s.k = t.k WHERE t.vt IS NULL AND s.ct = 'u';

A cursor that stops mid-way, for example a LIMIT inside a join's build side or a client that pauses fetching, still pins its shard, and sequences behind it fall back to reducing frame by frame on the query thread.

This fix restores diagnostics and offset counting for HORIZON JOIN. The JIT compiler could reuse an ArithmeticException without a message, causing a parallel HORIZON JOIN to report only unexpected reduce error; the checked addition used by the serial iterator is now also used during heap initialization and subsequent iteration, so a timestamp overflow consistently produces a non-critical exception carrying the timestamp and the offset.

For microsecond timestamps, RANGE FROM -9000000000000s TO 9000000000000s STEP 9000000000000s should produce three offsets but signed subtraction overflow previously reduced it to one; the span is now divided as an unsigned value and the configured limit is checked before adding one or narrowing the count, with counts beyond long reporting a truthful lower bound in the existing SQL limit error.

The timestamp helper still inlines and retains its intrinsic, and RANGE counting runs during query compilation so it adds no per-row work.

This fix addresses three problems with O3 merges into Parquet partitions after ALTER COLUMN TYPE. Previously, every O3 commit rewrote the entire Parquet file after a type change, because a column was treated as type-converted whenever its original writer index differed from its writer index; a column is now considered type-converted only when the type stored in the Parquet file also differs from the table's column type, so only the first merge after the ALTER rewrites the file and later merges take the in-place update path.

Second, an indexed SYMBOL column converted from another type kept a stale symbol index after an in-place O3 update, because the Parquet column lookup used the current writer index instead of the original one, causing indexed lookups to return rows that no longer matched the merged data. Third, after a VARCHAR -> STRING -> VARCHAR round trip the table writer moves the column to the end of its metadata while the Parquet file stays untouched, and the Rust Parquet updater encoded new and replaced row groups positionally against the file schema, writing values into the wrong columns or suspending the table; columns are now reordered to the file schema by Parquet field id when replacing or inserting row groups, with a clear error returned for unmatched or duplicate ids.

Additionally, horizon join timestamp overflow now reports a descriptive horizon timestamp overflow error instead of a bare internal reduce error.

This fix makes buffered log records visible promptly and lets the logging subsystem recover from failed rolls. The rolling file writer previously waited for 100,000 idle job passes before flushing, which could hold low-traffic records in memory for several minutes; it now flushes a non-empty buffer one millisecond after the latest buffered record, keeps the idle-pass count as a fallback, opens the active log path in append mode during startup, and reserves numbered-file creation for configured size or time roll events, so restarts no longer accumulate empty numbered files.

Failed rolls are now recoverable: the descriptor is reset immediately after the old file is closed, the roll deadline advances only after the new file opens, a flush always rolls when no file is open, and close() releases the buffer, descriptor and paths before rethrowing a flush error, so a failed rename, expired-log removal or open no longer stops file logging until restart or writes log text into an unrelated file.

In addition, only one log factory is now constructed per process: loggers requested during construction receive a deferred logger that is bound after initialisation, the logging worker pool starts without a logger so writer failures are reported on stderr instead of wedging the worker, and the writer rolls an existing file aside when an append open fails.

This halves the logging threads, configuration reads and native logger memory of a default server start, and a malformed log.conf now fails startup with a plain log error. A related overflow check was added to the zero-operand fast paths of Decimal128 and Decimal256 addition and subtraction, so checked operations never return an out-of-range value.

Concurrent PostgreSQL Wire Protocol queries could cause EXPLAIN CREATE TABLE ... AS SELECT and EXPLAIN CREATE MATERIALIZED VIEW to throw a NullPointerException when the compiler was reused before the plan was rendered, and could also produce incorrect table names or statement types in EXPLAIN INSERT and EXPLAIN UPDATE. This fix snapshots the table name and statement type information during compilation, so the EXPLAIN factory no longer retains a reusable execution model.

This fix corrects two SAMPLE BY ... FILL defects. Previously the bucket column was located in the GROUP BY output by name, so any TIMESTAMP output column sharing the timestamp's name was mistaken for the bucket, causing assertion errors, unbounded fill rows, too many rows for queries such as SELECT first(ts) AS ts, avg(val) FROM t SAMPLE BY 1h FILL(NULL), or dropped gap rows for a qualified timestamp_floor('1d', t.ts) AS ts; the optimizer now records the bucket key node it creates and code generation resolves the bucket by that node regardless of alias.

Second, an outer GROUP BY over a fill sub-query, such as SELECT ts, count() FROM (SELECT ts, avg(val) v FROM t SAMPLE BY 1h FILL(NULL)) WHERE v > 1.5 GROUP BY ts, received a second fill that re-inserted filtered gap rows and corrupted aggregates; the fill is now applied only when the GROUP BY output itself carries the recorded bucket node, while still running for fills inside a LATERAL body.

As a result, a time-series operator over an outer GROUP BY ts on a fill sub-query without an ORDER BY now fails with left side of time series join has no timestamp unless ORDER BY ts is added, SELECT first(ts) AS ts, avg(val) FROM t SAMPLE BY 1h FILL(0) now reports Invalid fill value: '0'. Timestamp fill value must be in quotes, and a projection selecting both a qualified and unqualified timestamp copy consistently returns a keyed fill for either column order.

This fix makes the Web Console send a valid bearer token on every request and recover from a 401 on its own, now that an HTTP session no longer falls back to the qdb_session cookie when the Authorization header is rejected. When acl.oidc.groups.encoded.in.token=true the bearer is the ID token, and its renewal is scheduled from the token's exp claim rather than the access token's expires_in, with a provider that omits the ID token reporting an explicit "Missing ID token" error instead of sending Bearer undefined.

The bearer is read at the moment each SQL, validation, CSV check/import or preference request is sent, and the login method is remembered per tab so stored REST or Basic credentials from another tab no longer replace an SSO bearer. Token refresh is now bounded and shared: queries wait up to 10 seconds for a renewal before their first request and again after a 401, transport, timeout, 429 and 5xx failures back off without logging the user out, and an expired bearer is never sent after a failed renewal.

A 401 executed no SQL, so the console refreshes and resends once; a 401 answered for an older bearer no longer logs the user out, and a 401 from any endpoint also closes the cookie session so the next SQL request asks the server for a new one. Failure handling gained a persistent renewal warning with "Sign in again", a recovery view with Retry instead of a blank console, sign-in failures reported on the login page, and a failed renewal surfaced in the query notification and in the Schema panel rather than as a SQL error or a blank tree.

When a session ends, uploads and settings saves already in flight finish while queries and pending writes are cancelled, the last result and the cached tables and columns are cleared, notebook refresh rounds and headless agent runs are superseded safely, and interrupted queries state whether they may have executed.

Notebook auto-refresh rounds keep the previous chart frame, saved snapshot and grid rows until a round reaches the server, CSV import table checks only update the file and name they checked so running uploads and edits are preserved, and telemetry now shares the console client so it no longer sends a stale startup bearer that would trigger a logout.

The uploader's notified-transaction watermark was overwritten by every transaction notification instead of only being raised. Because events are not delivered in transaction order — a rebased table can drain data for transactions 1 and 2 followed by a table-created event carrying transaction 0 — a trailing lower value dragged the watermark down, so the transaction log reader was never remapped and an idle rebased table retried forever instead of settling in the uploader index.

This fix only raises the watermark in the drain path, allowing the uploader to tolerate any event order while leaving the rebase ordering unchanged.

A queue segment published its frozenForEnqueues flag before bumping the tail by the freeze offset, while the empty check in tryDequeue() reads the flag before the tail. In the window between the two writes a dequeuer could pair a set flag with the pre-freeze tail and subtract the freeze offset from a tail that was never bumped, making the frozen clause always true and reporting the queue empty while it still held committed items; the full fence only ordered visibility, so the race occurred on x86 as well as ARM.

This fix bumps the tail before publishing the flag, so a set flag always implies a bumped tail and a clear flag with a bumped tail simply retries, adding no additional synchronization. It also repairs the sized ConcurrentQueue constructor, which validated its size argument and then ignored it, always allocating a 32-slot first segment.

This fix addresses two symbol-map correctness issues that could produce invalid symbol mappings. Previously, SymbolMapReaderImpl.updateSymbolCount() removed the wrong cache range when the visible symbol count shrank and left maxOffset at the previous high-water mark, so keyOf() could return a key outside the current symbol count; the symbol cache and maxOffset are now shrunk together with the visible symbol count.

Additionally, WalTxnDetails.saveSymbols() relied on an assertion to require dense Write-Ahead Log symbol diff keys, which production builds do not enforce, allowing sparse or invalid diffs to pass through without a useful diagnostic. Symbol diff keys are now validated at runtime, and if a diff is sparse, Write-Ahead Log apply reports the relevant transaction and symbol metadata and suspends the table instead of applying a potentially inconsistent mapping, favoring containment over continuing with an invalid mapping.

The validation adds a single integer comparison per new symbol diff entry on valid input and no per-row work, but a suspended table requires operator intervention.

This fix addresses a race in the uploader's shared <db_root>/.upload scratch directory. Because the path is derived from the database root, it is shared across uploader generations, so during a teardown-and-rebuild role-switch cycle such as a hot switch or a refused-demote heal, the old uploader's final reference could unwind after the new uploader had already recreated the directory, and its drop then deleted the scratch directory out from under the live uploader.

The compression path only checked that the directory existed, so from that point every upload failed with tmp path does not exist in a permanent retry loop, leaving a healthy-looking primary with replication silently wedged until restart. Temporary archive creation now recreates the directory tree instead of merely checking it, which is a no-op when the directory exists, self-healing when a stale teardown removed it, and still an error when a non-directory occupies the path.

In-flight archives are unaffected by a concurrent delete because anonymous temporary files are used, so the next call converges.

This fix prevents data loss on the safe demote path. When an upload audit refuses a demote, the node is meant to keep its committed-but-not-uploaded Write-Ahead Log data, park read-only in a degraded replication state, and heal back toward primary to drain the backlog. However, the refusal arm still closed the primary role state and cleared the upload-mode latch that UploadWalDirectoryPolicy.isSeqPartInUse was gated on, so every V2 sequencer part reported as free and the node's own purge job deleted the applied transaction-log parts belonging to the very backlog the audit had declined to abandon.

After healing, the rebuilt uploader could no longer read the range it had to ship and retried indefinitely, so acknowledged transactions became permanently unreplicable while the local table continued answering queries normally. The policy now carries an explicit unresolved-demote-backlog pin meaning the node owes a backlog it cannot currently upload, and part markers are honoured when either the upload-mode latch is up or the pin is set.

The pin is set on both demote arms before the close that clears the latch, so no purge sweep can observe a window with neither flag set, and it is released only where the node is proven to owe nothing: a clean demote drain audit, or a retry toward replica in which every residue table has been explicitly sacrificed.

A node that was never primary in the current process never sets the pin, so a plain replica keeps reclaiming its downloaded parts unchanged.

Metadata hydration can construct table sequencers as soon as the engine becomes ready, so installing the upload-aware WAL directory policy later left a race in which a sequencer captured the default policy for its lifetime, never created V2 sequencer-part upload markers, and allowed the WAL purge job to remove a part before catch-up uploaded it.

This fix installs a single upload-aware policy immediately after the base server constructor returns and before lifecycle startup publishes engine readiness, and the engine keeps that policy instance throughout startup and role switches. The policy also preserves segment upload obligations across inactive and demoted roles: WAL writers record segment and sequencer-part markers while the server runs with role NONE so a later primary restart can discover retained work, and a segment is reported in use if either the upload-pending or download-pending marker exists, read under a single upload-mode snapshot so a concurrent role switch cannot probe the same marker family twice.

Per-part sequencer markers stay mode-gated and are ignored in download mode, so a replica or demoted primary with no live uploader does not treat them as purge locks and cannot grow the sequencer part directory without bound.

A live view's files can reach a replica before its base table's, so registration fails and is retried on a later poll; if the node restarts first, boot finds the view definition on disk with no state file, refuses to load it and registers a dead stub that occupies the view's slot forever, leaving the view permanently empty because a replica refreshes live views locally.

This fix drops the stub and rebuilds the view when a registration finds a live view with no state file and only a stub registered, so the view is left unregistered and retryable rather than stuck behind a stub if the base table is still missing. The recovery no longer unlinks and re-copies the definition file, which previously left a window in which a concurrent CHECKPOINT CREATE could abort or capture a snapshot whose restore deleted the view's data directory.

Genesis now stages the state file through a temporary file and renames it into place, so a failure or crash anywhere inside the first write leaves the state file absent rather than present but unreadable; a stale staged file left by a crash is removed before writing and the registration is refused and retried when that removal fails.

The on-disk format is unchanged and the state file stays node-local, so mixed-version clusters and rolling upgrades are unaffected.

This fix corrects scalar sub-query predicate handling and timestamp interval pruning, covering scalar sub-query bound hoisting, lateral count compensation, constant-false pruning in the interval model, and LATEST BY external-source propagation. As part of it, the rejection of UPDATE statements with a join on WAL tables is hoisted ahead of code generation, so on a WAL table the unsupported-shape error is now reported before column-level SELECT authorization runs; the non-WAL path is unchanged and still reaches the permission check.

This fix corrects current_user() and session_user(), which always returned the hardcoded default admin regardless of which user actually authenticated, so the Web Console displayed admin for everyone on page load, including a configured http.user or a PostgreSQL Wire Protocol user. The root cause was that the allow-all and read-only security contexts reported a fixed principal instead of the authenticated one.

AllowAllSecurityContext and ReadOnlySecurityContext now carry a principal field and expose forPrincipal(principal), and the security context factories pass the authenticated principal through it. Anonymous requests allocate nothing, and derived contexts are cached per principal so the HTTP path, which re-derives the security context on every request, becomes allocation-free after the first request for a given user; the cache is bounded at 256 principals, past which an unseen principal degrades to allocate-per-call rather than growing without limit.

DenyAllSecurityContext and the materialized view refresh context are never re-derived, so they cannot be downgraded to a read-allowing context, and the transient principal is copied before it is retained. current_user() and session_user() are now runtime-constant functions that snapshot the principal in init() rather than reading it once per row, so a 1000-row query performs a handful of security context reads instead of roughly one per row, while a context re-derived between executions of a cached SELECT is still picked up.

This fix stops TableReader from closing a column's file descriptor immediately after mapping it for every partition except the currently growing last one. Because the file descriptor and memory-map caches can only reuse an existing mapping while its file descriptor is still open, a later, non-overlapping reader that opened the same historical partition always created its own independent mapping.

Under workloads with many long-lived, concurrent readers scanning the same large table, such as dozens of parallel connections pulling a multi-terabyte table in time-ordered batches, those duplicate mappings accumulated and could exhaust the process's virtual address space with could not mmap errors even while resident memory usage stayed low.

A column's file descriptor is now kept open for as long as the reader keeps the column mapped, for every partition, so concurrent or staggered readers of the same partition share a single mapping. The trade-off is higher file descriptor usage: a reader now holds one descriptor per currently mapped column for as long as cairo.inactive.reader.max.open.partitions (default 10,000) lets it keep that partition open, so deployments with many partitions, columns and concurrent readers should ensure their ulimit -n has headroom.

This fix prevents ALTER TABLE ... ALTER COLUMN ... TYPE from crashing the whole JVM with a native SIGBUS when disk space was low instead of failing the statement with a normal error. The destination column file was sized with ftruncate(), which only sets the logical file length and does not reserve real disk blocks, so a later native write into an unbacked page faulted with SIGBUS, which cannot be caught from Java or JNI.

Disk space is now reserved via TableUtils.allocateDiskSpace() (posix_fallocate), matching every other writable memory-mapping call site in the codebase, so a disk space shortfall surfaces as a catchable CairoException.

This fix prevents an idle live view fallback scan from durably invalidating a healthy view while another refresh worker processes a new base table commit. The fallback scan validates restored or replicated state by invalidating a view whose processed sequencer transaction is ahead of its base table, but it sampled the base sequencer head first and the view watermark second.

A notification worker could publish and refresh the next base transaction between those two reads, so the fallback worker compared an old base head with a new view watermark and persisted a false "view is ahead of base table" invalidation. The view watermark is now read and retained first, followed by the monotonic base sequencer head, with those same retained values used for both the comparison and the diagnostic log.

Since a refresh publishes the watermark only after consuming the corresponding base sequencer transaction, a newer watermark can no longer be paired with an older base head, and the impossible combination is eliminated without adding a lock on the hot path. Genuine restored or replicated ahead states still take the existing invalidation path.

This fix stops squashSplitPartitions from destroying the tail of a variable-size column (BINARY, STRING, VARCHAR) in the partition it squashes into, which produced silently wrong query results, binary is outside of file boundary errors, or unsafe memory access faults. The squash appends into the target partition through the frame's own file descriptors; when that target is the partition the writer still holds open, the writer's column append memories keep their pre-squash positions and describe a shorter file than what is on disk, so the stale append memory trims the grown data vector back on close and a later memory re-extends it zero-filled, cutting the last value's length prefix in half.

This state is reachable because opening the last partition is a no-op when that partition is Parquet, leaving the writer pinned to an earlier native partition, for example after ALTER TABLE ... SET FORMAT PARQUET followed by an insert into a later day. When the squash target is the writer's open partition, the stale view is now dropped by closing without truncating and the target is re-opened so the writer resumes from sizes that match disk, with both arms running under a single distress guard.

The posting index seal-purge outbox is now drained before closing the active partition in the squash path, so superseded index files are published for purging instead of leaking on disk.

This change also hardens posting index publishing and closing: close() no longer sizes a mapping up just before releasing it, several call sites now arm the seal transaction tag before publishing, and the reader rejects structurally impossible or all-zero generation metadata. As a user-visible consequence, the reader's error now names the affected column and the recovery step, for example posting index is corrupt, rebuild it with REINDEX TABLE <table> COLUMN <column> LOCK EXCLUSIVE, and a query over a damaged index that previously returned a silently short result now raises an error instead.

This fix addresses two independent defects that could permanently invalidate a live view over a healthy base table, even for a column the view never referenced. First, WAL symbol map folding was coupled to every symbol column carrying a diff, ignoring the projection supplied by the caller; because WAL symbol dictionaries are shared across segments and deleted as soon as a DROP COLUMN is applied, a live-view drain could fault on a dictionary belonging to a column outside its projection.

Symbol map folding now skips diffs for columns the effective projection does not reach, while a rebind that widens the projection still refolds from the start of the event file so all symbol values resolve. Second, the re-derive path that rebuilds a view from the applied base table after WAL loss replayed through a cached compiled plan and was refused whenever base metadata had moved on, which is the normal state during the DDL churn that triggers it; it now recompiles once and retries the replay.

A shared guard reads the base's applied metadata ahead of both replay attempts and refuses to re-derive when a referenced column was dropped, renamed or retyped, invalidating the view and naming the column rather than silently committing results computed over a new schema. A common trigger was ALTER TABLE base ALTER COLUMN sym SYMBOL CAPACITY N, which is non-structural and deliberately leaves dependent live views valid, but causes the next WAL segment roll to delete and re-link the dictionary.

The re-derive is a full rebuild from the applied base rather than an incremental drain, so recovery carries a one-off cost on the refresh worker, and the projected WAL reader overload now reports 0, null and not-found for symbol columns outside the projection.

This fix prevents PostingIndexWriter.close() from trimming the .pk file below the chain region another writer instance had already published, which physically destroyed the tail of the most recently published chain entry. Because more than one writer can be open on the same .pk file, the closing instance's cached high-water mark could lag the file, and the lost bytes read back as zeros, corrupting the generation directory and silently dropping rows from POSTING index scans.

The writer now never trims below the region limit published in the chain header, the authoritative live high-water written under the header seqlock. Three further defects are addressed: publishing could itself write a regressing seal transaction when an extend happened on a reopened writer, so a slot is now clamped up to its predecessor and a monotonicity check runs immediately after the slot store and before publication, throwing a diagnostic exception instead of aborting via an assertion; the reader no longer asserts gen-dir monotonicity inside a window where torn reads are legal, and instead records the anomaly and acts only once the snapshot is proven self-consistent; and the reader now closes the release half of the entry seqlock by re-reading the generation count and retrying, so an entry rewritten in place with a smaller count cannot mix two incarnations.

Genuine corruption now raises a diagnostic error naming the entry offset and generation counts. Additionally, close() no longer propagates errors on a cleanup path that must not throw, logging instead and leaving the file intact for the next open when no trusted high-water is available. A .pk file already damaged by an earlier build does not self-heal; rebuild the index with REINDEX TABLE <table> COLUMN <column> LOCK EXCLUSIVE;.

This fix resolves a crash when reading metadata for tables created before QuestDB 6.1. The per-column replacing index was followed straight out of the _meta file without validation, but on migrated tables that slot holds leftover junk, because the migration grew column entries from 16 to 32 bytes and left old file contents in the bytes it did not write, with every later rewrite copying the junk forward.

An index past the column count read off the end of the mapped file, and one pointing forward read off the end of the dense column list; with assertions disabled both were silent out-of-bounds reads that fed garbage into column mapping. The replacing column index now returns -1 unless the value could have come from a real replacement, meaning it is below the column carrying it and points at a deleted column, so every chain walk is in-bounds and loop free and both cycle guards were removed.

Affected tables clear the junk on their next ALTER, which rewrites the column block from in-memory metadata. As a tradeoff, a genuine chain whose bytes were corrupted now degrades silently rather than erroring.

This fix eliminates an ERROR-level log line per view on every start of a database containing views, which read like corruption despite the view definition files being present and intact. View definitions are loaded from disk into the view graph and state store by the worker pool manager, but the hydration components depend only on the engine, so as soon as the engine published READY the view compiler and metadata hydration threads walked the table name registry with an empty graph, reporting missing view definitions and skipping views during write tracker hydration.

As a result, compiling all views at boot was a no-op on every start, masked only by the per-view compile requests issued later. Loading of view definitions now runs in the engine startup step, immediately after the engine loads table state and before READY is published, so every engine-gated component observes a fully loaded graph.

No client-visible failure occurred previously, since the shared pools serving PostgreSQL Wire Protocol and HTTP only start after the graph is populated.

This fix tightens an internal memory bounds check so that invalid writes fail safely instead of corrupting memory. The issue was found internally and no production workload is known to trigger it. There are no SQL, API, or configuration changes.

This fix restores correct covering-index reads across Parquet format conversions. Converting a partition with a COVERING posting index to Parquet and back to native rebuilt the posting index from the decoded native data without the covering sidecar files, so covering scans returned NULL for every covered column or failed with an index-out-of-bounds reduce error, while the underlying native data remained intact.

The conversion back to native now hard-links the existing key, value and covering sidecar files from the Parquet partition directory into the new native directory, mirroring what the native-to-Parquet direction already does, which also removes the index rebuild work for plain bitmap symbol indexes.

Converting to Parquet had the same defect in the opposite direction whenever the indexed symbol column had a column top: the rebuild that materialised the leading NULL prefix produced key and value files only, and both directions now share a single index rebuild routine that configures covering when needed.

As a behavioural change, the link path gates on the key file alone, so a Parquet partition directory holding a key file with no resolvable live value file now fails the conversion with an "index files do not exist" error, suspending a WAL table, rather than silently rebuilding a non-covering index; reaching that state requires out-of-band file loss or a crash during index creation.

Building covering sidecars on the column-top path also makes CONVERT PARTITION TO PARQUET do index work proportional to rows times covered columns where it previously did almost none.

ALTER TABLE t ALTER COLUMN sym ADD INDEX TYPE POSTING INCLUDE (price, tag);
ALTER TABLE t CONVERT PARTITION TO PARQUET LIST '2024-01-01';
ALTER TABLE t CONVERT PARTITION TO NATIVE LIST '2024-01-01';
SELECT sum(price), first(tag) FROM t WHERE sym = 'A0';

This fix prevents a WAL table with a POSTING index from being suspended mid-apply during a partition squash. Under parallel WAL apply, reopening a column's key file sized the memory mapping from the reported file length, which can lag the writer that just extended the file, so the chain's head entry fell outside a short mapping and was read past its end, distressing the writer and suspending the table.

The reopen now reads the header's live entry-region high-water mark through a seqlock-consistent header read and extends the mapping to cover it only when the reported length genuinely lags, leaving the common case with no extra remapping, and the header is range-checked before its values are trusted so a corrupt header raises a CairoException instead of an out-of-mapping read.

A second fix stops the key file from being truncated when a reopen fails before the region is republished: the failure path now releases the mapped memory without truncation, leaving the on-disk index intact for the next open and removing a latent hazard where the file could be truncated while still mapped by concurrent readers. Neither change alters how the key file is written or the on-disk format.

This fix replaces an invalid native memory access with a controlled error when a POSTING index writer is rolled back after an I/O failure closed its mapped value file.

Previously, a failed remap while flushing pending data, or a failed open of the replacement value file during truncation, left the writer holding live key or pending state over a closed mapping, so a later rollback could re-enter the flush or reencode path and produce an assertion failure, a null facade access or a native memory crash.

The flush and reencode paths now reject work over a closed value memory with a CairoException before any scratch allocation or index mutation, and closing mapped read-write memory now clears its append bounds so stale addresses from a released mapping can no longer be accepted without remapping. Table-level recovery is unchanged: the caller still distresses and discards the affected writer, and the on-disk chain is recovered on the next open.

This fix prevents a table from being suspended after a REPLACE_RANGE WAL commit, used by materialized view refreshes and range-replace inserts, removes the table's last partition. The commit moved the writer's maximum timestamp back to the new last partition but left the partition timestamp boundary pointing at the removed partition, since the replace path only ever advanced it and never lowered it.

The usual re-sync that re-opens the new last partition is skipped when that partition is Parquet, so the next non-replace commit applied by the same writer tripped a partition-timestamp consistency check and suspended the table. The partition-removal branch now re-derives the partition timestamp boundary from the final maximum timestamp after partition sizes are updated, which runs only for replace commits that removed or trimmed partitions and leaves the native last-partition behaviour unchanged.

A query that waits, such as sleep(), wait_wal_table(), or any long scan that periodically consults the SQL circuit breaker, could keep running after its client had already disconnected, holding the connection's socket descriptor and worker resources until the query reached its own deadline. This fix replaces the peek-based connection probe with a hangup probe that detects a FIN behind buffered data on all platforms, including Windows, using poll(POLLRDHUP) on Linux, kqueue with EVFILT_READ/EV_EOF on macOS and FreeBSD, and WSAPoll on Windows.

Previously a clean client close sent an application byte before the FIN, so the peek returned buffered data instead of EOF and the breaker never tripped, letting the query run until query.timeout (60 seconds by default).

This fix also wires a real, file-descriptor-backed circuit breaker into the QuestDB WebSocket egress query path, covering compilation, cursor acquisition and the result-streaming loop, so egress queries now honour query.timeout and abort with STATUS_LIMIT_EXCEEDED instead of streaming past the deadline; a stream resumed after a write park or credit grant re-checks the deadline and the connection before producing the next batch.

A request-boundary reset that disarmed the breaker of a parked, protocol-switched stream is corrected, and connection probes are now throttled by wall clock (100 ms by default) so the file-descriptor-backed breaker does not turn hot loops into per-iteration syscalls, at the cost of up to one throttle window of detection lag per checking site.

Bulk data phases such as INSERT AS SELECT, CREATE TABLE and UPDATE remain exempt from query.timeout by design. The now-obsolete circuit.breaker.buffer.size and net.test.connection.buffer.size settings are removed and log an advisory on start-up, or fail under config.validation.strict.

A double-read race in WriterPool.Entry.getTableToken() that could throw a NullPointerException when a writer_pool() scan raced a writer close is also fixed.

Restore cancellation was previously signalled only from a component's stop(), which runs inside the reverse-topological stop loop that follows the bounded boot-thread join, so a SIGTERM landing during a long point-in-time restore burned the entire 30-second join budget before the restore was asked to unwind, and a pod with a 30-second termination grace was killed mid-restore.

This fix adds a pre-join cancel hook that runs after the executor drain and before the boot join, so the join budget is spent unwinding the restore; the hook contract is a pure, non-blocking cancel signal, resource teardown stays in stop(), and a throwing hook is logged rather than propagated so it cannot abort the shutdown it was installed to accelerate.

Materialized view hydration now accepts an explicit target state store, allowing a caller to hydrate a private, not-yet-installed store and publish it only after hydration completes, with closing checks that abort the load promptly; the state store's close() is now idempotent across sequential closes and clears its map after freeing state, preventing a double free.

A non-creating suspension-tracker lookup is added for hot read paths such as metrics scrapes, where a missing tracker simply means the table was never suspended. Finally, a broken duplicate-log assertion in the logging test helper was corrected, which exposed and fixed a real bug where every CREATE TABLE and system-table creation logged two completion records, one premature record carrying a -1 sentinel id; completion logging now belongs entirely to the execution site, so a CREATE that is compiled but never executed emits no completion record at all.

On a primary, an apply-time invalidation could publish while another refresh worker held the same view latch; the losing worker queued a retry, but the pending-marker guard consumed that retry without minting durable invalid state or arranging another wake-up, freezing the view in a stale-but-valid state.

This fix introduces a single atomic pending marker with independent invalidation and full-refresh facets, carrying the invalidation reason, base table token, base transaction, force flag and a distinct full-refresh owner, merged keep-strongest so force flags OR, same-token transactions keep the maximum, and unknown or mismatched provenance collapses to conservative.

An invalidator publishes the marker before attempting the view latch and either handles it itself or lets the completing latch holder queue one authoritative wake-up, so a contention episode produces bounded queue traffic. All operational latch holders, including incremental, range, interval, full, invalidation and synchronous REFRESH ... STATS paths, release through a common finalize helper that runs cleanup before publishing follow-up work.

Full refresh is now snapshot-aware: it records its fixed reader snapshot and clears an invalidation only when the base table token matches and the snapshot transaction covers the invalidation transaction, while unknown provenance, a different table epoch or a newer transaction keeps the invalidation pending.

An authorization refusal from the read-only writer gate, such as a replica demote racing a refresh, is now treated as a transient role condition that defers instead of trapping the worker in an unbounded requeue loop. Suspended views retain pending invalidation and full-refresh facets and republish them after a successful RESUME WAL, and invalidation now cascades to dependent views only after an invalid state is durably persisted, so a declined invalidation no longer leaves children invalid.

If queue growth fails, allocation-free retry flags are recorded on the view state and redelivered by a later refresh-job tick.

On Windows the writer temporarily grew the small .pci cover-info file to the data-index append page size (1 MiB in tests, 16 MiB on a server) and truncated it back on close, so a concurrent reader could observe the larger length and map the file after it had shrunk, failing with errno 8. This fix maps .pci at a page-aligned size derived from the payload and any existing size and parks the append pointer there, making the physical file size monotonic non-decreasing for the file's life so a reader's length-then-map sequence can never map past a shrink; a larger existing file is preserved rather than shrunk.

On adjacent paths, the .pci header is now rewritten only when it is absent, shorter than the payload, or its magic, count or covered-column indices disagree with the live configuration, repairing corruption instead of rewriting unconditionally on every seal. The sync order now fsyncs .pv, each .pcN and .pci before .pk, so a covering commit can no longer leave a durable chain head over cover bytes that were never flushed, and a failure to read the length of an existing .pci now throws instead of being silently treated as a new file.

Under SYNC and ASYNC commit modes each covering commit issues up to one additional sync per covered column plus one, which is inert under the default NOSYNC.

On x86 systems with SQL JIT enabled, a valid query that checks a STRING column for NULL could rarely crash QuestDB with SIGSEGV when a null or empty string header occupied the final four bytes of a mapped column file, for example SELECT status, count() FROM events WHERE status IS NOT NULL GROUP BY status.

This fix makes the scalar JIT read the four-byte STRING header without crossing the mapping boundary. Before upgrading to a fixed version, the crash can be avoided by setting cairo.sql.jit.mode=off and restarting QuestDB.

Decorrelation rewrites a scalar-aggregate lateral body into GROUP BY plus LEFT JOIN, which loses the empty-group row; the previous compensation only recognised bare count() projections, so unmatched rows returned NULL for count(*) + 2, CASE WHEN count() = 0 THEN 7 ELSE count() END, count_distinct(x), approx_count_distinct(x) and for sibling columns of a count, and WHERE sub.cnt = 0 filtered out the very rows it was meant to select.

This fix builds a compensation template for any projection containing a zero-on-empty aggregate (count, count_distinct, approx_count_distinct), extracts aggregate leaves into hidden carrier columns and wraps only zero-on-empty leaves in coalesce(x, 0), so count(*) + sum(v) correctly stays NULL while count(*) + 2 returns 2; constants, outer references and bind variables now carry their value onto the compensated row, and WHERE terms referencing compensated columns are hoisted above the null-extension boundary so they observe 0 rather than NULL.

Keyed bodies — an implicit GROUP BY key, a SAMPLE BY body, or a WINDOW JOIN / HORIZON JOIN body — are no longer treated as scalar and correctly return NULL instead of a fabricated 0, while CROSS JOIN LATERAL and INNER JOIN LATERAL over a scalar aggregate body are promoted to LEFT OUTER so they preserve every outer row.

PIVOT empty cells for approx_count_distinct now default to 0 instead of NULL, and the expression parser accepts count(*) in any expression position, so coalesce(count(*), 5) and count(*) + count(*) compile, including inside OVER() window specifications where :: casts and multi-WHEN CASE expressions were broken in the same way.

A negative LIMIT reaching a lateral body through a bind variable or an outer column now fails with negative LIMIT is not supported in a correlated lateral sub-query instead of silently emptying the body.

LATEST ON over an indexed SYMBOL column with a PostgreSQL Wire Protocol bind variable could return the latest row of a previously queried key, making the WHERE filter appear to be silently ignored. LatestByValueDeferredIndexedRowCursorFactory did not override RowCursorFactory.init(), which is a no-op by default, so the symbol function was never re-initialised and kept pointing at the bind variable service of the execution context that originally compiled the factory; once the shared SELECT query cache handed the cached factory to another connection, the resolved symbol key belonged to a different connection's bind variables.

This fix forwards init() to the symbol function, restoring symmetry with the sibling deferred symbol index factories. Only indexed columns queried through bind variables on fresh connections were affected; literals and casts such as $1::SYMBOL resolved through other paths and were always correct.

VARCHAR date and timestamp conversions could produce different results for native and Parquet-backed partitions, potentially excluding valid rows from queries. This fix treats a negative ASCII hint as unknown and inspects the actual bytes, preserving the ASCII fast path while supporting Unicode patterns and timezones.

It also makes malformed UTF-8 handling atomic across SQL conversions, Parquet and O3 processing, row copying, TableWriter, WAL and Influx Line Protocol ingestion, so invalid input becomes NULL instead of exposing or persisting a valid prefix. Before upgrading, the original parsing issue can be worked around with an explicit format, for example to_timestamp(trim(TimeCreated), 'yyyy-MM-dd HH:mm:ss.SSS').

QuestDB now accepts SHOW CREATE DATABASE as a parenthesized query source in FROM, CTE and JOIN contexts, while filters and INCLUDE (...) / EXCLUDE (...) clauses keep their existing top-level behaviour. The parser previously read clause delimiters with helpers that consumed a closing ) as the enclosing subquery terminator, so the outer parser lost either the SHOW subquery delimiter or the category-list delimiter.

This fix reads optional-clause lookahead without consuming the enclosing delimiter and returns it through the existing unparse path, reading the category list's own closing delimiter locally. Valid top-level statements are unchanged; malformed input that closes a valid category list but omits the enclosing subquery delimiter now reports the more specific error ')' expected instead of ',' or ')' expected.

This fix corrects dot_product() over two DOUBLE[]/DOUBLE[][] arrays, which could silently return a wrong result when one operand was not stored in vanilla (contiguous, row-major) layout. In the recursive code path the deepest-dimension loop read the right-hand array using the left array's flat index instead of its own cursor, so operands with different strides — for example a transposed array or a slice — selected the wrong elements.

For instance, transpose([[1,3],[2,5]]) combined with [[1,5],[7,2]] now correctly yields 42 instead of 40. Arrays already stored in identical vanilla layout are unaffected, and there is no performance impact since the change simply uses an index variable that was already maintained.

This fix allows SAMPLE BY w to parse correctly, where it previously failed with one letter sample by period unit expected even though every other single-letter sampling unit, such as SAMPLE BY h, SAMPLE BY d and SAMPLE BY M, worked without a leading digit and users had to write SAMPLE BY 1w as a workaround.

The parser's allow-list for the bare single-letter form was missing w, rejecting the query before it reached the sampler, even though the week unit was fully supported downstream by both the micros and nanos timestamp drivers. The change only widens what the parser accepts, with SAMPLE BY w now behaving identically to SAMPLE BY 1w, and does not alter the behavior of any query that already parsed.

This fix addresses several correctness and resource-safety issues in parallel SQL execution. first_not_null() and last_not_null() now behave correctly for IPv4 columns on the non-sharded keyed-batch path, implementing the same keyed-batch semantics as other primitive types, and batched last_not_null() implementations replace stored NULL values consistently with their row-by-row and merge paths.

dim_length() now returns NULL for NULL arrays, NULL dimensions, and NULL PostgreSQL Wire Protocol array binds, while non-NULL out-of-range dimensions still report an error. Parallel reducers — including parallel filters, GROUP BY, top-K, horizon joins, multi-horizon joins, and window joins — now release their worker slot from a finally block entered immediately after acquisition, so a failure during frame navigation, temporary allocation, or cleanup can no longer permanently leak a slot and leave later executions of a cached factory spinning forever.

A data race on the selectivity statistics shared across threads by a thread-safe parallel filter is resolved by packing the sample count and average into a single volatile word updated with a CAS loop, guaranteeing both consistency and visibility for the late-materialization heuristic. Array access overhead is reduced by reading dimension and element data directly through record accessors rather than materializing an ArrayView per row, NULL-producing records consistently return a NULL ArrayView, and the shared NULL array constant uses a borrowed array so an accidental close cannot mutate global NULL state.

A dead VARCHAR entry was also removed from the CaseCommon dispatch table, which changes no behavior.

This fix resolves a lifecycle race where CANCEL QUERY <id> could cancel a different, unrelated query after the registry recycled a pooled query entry, causing the victim query to fail with cancelled by user even though nobody cancelled it. Cancellation now only applies to the active query that owns the requested id: each pooled entry carries a volatile lifecycle word packing the owning query id and a state, so a stale canceller holding a recycled entry fails the lifecycle check and reports the query as not found instead of cancelling the new owner.

query_activity() now snapshots registry entries optimistically and only returns a row if the entry still belongs to the same active query after the row has been copied, preventing torn rows and wrong-query data while entries are unregistered and recycled. The cost is one volatile lifecycle publish on query registration and one uncontended CAS when unregistering, and a query in the cancelling state may transiently not appear in query_activity() while a canceller holds the lifecycle guard.

This fix resolves cases where some queries returned nothing over the PostgreSQL Wire Protocol, leaving the client blocked in fetchall() until the idle timeout closed the connection, five minutes later by default, while the server log showed the query finishing normally followed by an idle disconnect.

The server was sending a DataRow header announcing more bytes than it went on to send, which occurred with ARRAY columns in text format when the client sends per-column format codes, and with IPv4 and GEOHASH columns requested in binary. Drivers that send a single result format code, such as psycopg2 and JDBC in its default mode, were never affected.

As a tradeoff, rows that genuinely exceed pg.send.buffer.size now fail with an explicit error naming the required size instead of hanging, so jobs that previously hung will now report a failure.

Selecting a DECIMAL column over the PostgreSQL Wire Protocol could fail with unsupported type: 31 when a binary response crossed the server send-buffer boundary, because decimal types were missing from the calculation used to size the unsent tail of a fragmented DataRow. This fix adds exact PostgreSQL NUMERIC binary-size calculation for DECIMAL8, DECIMAL16, DECIMAL32, DECIMAL64, DECIMAL128 and DECIMAL256, accounting for nulls, zero, sign, precision, scale and base-10000 digit grouping, reuses the execution context's decimal scratch values for the 128-bit and 256-bit widths so the response path does not allocate, and adds a text-size estimate for decimal columns.

It also introduces DecimalFunctionMemoizer, registered by SqlCodeGenerator for all decimal widths, so that a projected non-deterministic decimal function such as rnd_decimal() returns a stable value per row; sizing and serialization therefore stay aligned. The memoizer applies to every projected DECIMAL column on all protocols whenever the alias is read more than once or the function reports shouldMemoize().

Decimal storage and the binary encoder are unchanged. INTERVAL and ARRAY_STRING columns still have the same gap in the size calculators.

A client speaking a non-Influx Line Protocol binary protocol on the Influx Line Protocol TCP port caused the server to log an unhandled critical error, because EllipticCurveAuthenticator.readKeyId() converted raw key-id bytes to a String eagerly and threw CairoException on invalid UTF-8, which handleAuthentication() did not catch.

Since nothing on that path closed the connection, every such connection permanently leaked a file descriptor, its receive buffer and one of the 256 default connection slots, and incremented the unhandled_errors counter exported to Prometheus. This fix validates the key id with Utf8s.validateUtf8() before conversion, so an invalid key id follows the same path as an unknown key: a single log line followed by an AuthenticatorException and disconnect.

Both key-id log lines now render bytes with $safe(), hex-escaping control characters that an unauthenticated peer could previously write raw into the log. A CairoException catch is added around authenticator.handleIO(), which also closes a second instance of the same bug where a signature line that is not valid base64 stranded the connection, and the catch follows the severity and errno of the exception rather than forcing them.

Finally, both the authenticator call and the security context factory call catch Throwable, logging it as critical, counting it as an unhandled error and disconnecting, so nothing escaping the authenticator can strand a connection. There is no configuration or protocol change and no behaviour change for well-behaved clients.

The documentation restructure moved ingestion/* to connect/*, which broke every client, Influx Line Protocol, PostgreSQL Wire Protocol, REST API and message-broker link in the English and Simplified Chinese READMEs. This fix repairs all dead documentation links in both files, reframes the Connect to QuestDB section around QWP as the native protocol with Influx Line Protocol, PostgreSQL Wire Protocol and REST presented as compatibility protocols, adds a link to the connect overview, retitles "First-party ingestion clients" to "First-party clients" since those clients now cover both ingestion and queries over QWP, and completes the deployment list with systemd, Azure, Hetzner and ZFS compression ordered to match the documentation sidebar.

This fix moves engine.buildViewGraphs() into the engine lifecycle envelope, so _view definitions are read from disk into the view graph and state store immediately after the engine loads its table state and before it publishes READY.

Previously the graph was populated later, when the worker pool manager started, so components gated on engine readiness — the view compiler job and metadata hydration — observed an empty graph and logged an ERROR-level cannot compile view, missing view definition line for every view on every start, together with a view does not exist message while hydrating the write tracker.

Startup compilation of all views was effectively a no-op, masked by the per-view compile requests issued once the graph was finally built, and the write tracker silently skipped views. No queries were affected, because the shared pools serving PostgreSQL Wire Protocol and HTTP only start after the graph is populated; worker pool construction now remains the sole responsibility of the worker pool manager step.

Tables migrated from the pre-6.1 layout carried junk in the per-column replacing index slot of _meta, because the migration grew column entries from 16 to 32 bytes and left the old file contents in the bytes it did not write, with every later rewrite copying the junk forward. Following that index produced an assertion error or, with assertions disabled, silent out-of-bounds reads past the mapped file or the dense column list that fed garbage into column mapping.

This fix validates the value before it is used: a replacing index is only accepted when it could have come from a real replacement, meaning it sits below the column carrying it and points at a deleted column, and anything else is treated as "no replacement", matching the behaviour of the versions that wrote those bytes.

Every chain walk is therefore in-bounds and loop free, and affected tables clear the junk on their next ALTER, which rewrites the column block from in-memory metadata. As a tradeoff, a genuine replacement chain whose bytes were corrupted now degrades silently rather than raising an error.

Some queries returned nothing over PostgreSQL Wire Protocol, leaving the client blocked until the idle timeout closed the connection while the server log showed the query finishing normally. The server was sending a DataRow header that announced more bytes than it went on to send, which happened for ARRAY columns in text format when the client sends per-column format codes, and for IPv4 and GEOHASH columns requested in binary format; drivers that send a single result format code, such as psycopg2 and JDBC in its default mode, were never affected.

As a tradeoff of this fix, rows that genuinely exceed pg.send.buffer.size now fail with an explicit error naming the required buffer size instead of hanging, so jobs that previously hung will report a failure.

A LATEST ON query over an indexed SYMBOL column with a PostgreSQL Wire Protocol bind variable could return the latest row of a previously queried key instead of the requested one, with the WHERE filter silently appearing to be ignored:

SELECT Enabled, AttributePath, DeletedDate
FROM AttributeList
WHERE AssetKey = $1
LATEST ON Timestamp PARTITION BY AssetKey;

The deferred indexed row cursor factory did not override the row cursor factory init() method, which is a no-op by default, so the bind variable function was never re-bound to the current execution context. Once the shared query cache handed the factory to another connection, the stale value belonged to a different bind variable service.

This fix forwards initialisation to the symbol function, restoring symmetry with the sibling deferred symbol index factories. Queries using a literal value, an explicit ::SYMBOL cast, or an unindexed column were never affected.

VARCHAR date and timestamp conversions could produce different results for native and Parquet-backed partitions, potentially excluding valid rows from queries. This fix treats a negative ASCII hint as unknown and inspects the actual bytes, preserving the ASCII fast path while correctly supporting Unicode patterns and timezones.

It also makes malformed UTF-8 handling atomic across SQL conversions, Parquet and O3 processing, row copying, TableWriter, WAL and Influx Line Protocol ingestion, so invalid input becomes NULL instead of exposing or persisting a valid prefix.

A live view could become permanently invalid over a healthy base table, for a column it never referenced, with the only remedy being DROP plus CREATE. Two independent defects caused this. First, the WAL reader folded a symbol map diff for every symbol column that carried one, ignoring the projection passed by the caller, so a live-view drain could open the WAL symbol dictionary of a column removed by ALTER TABLE ... DROP COLUMN even though the view's query never mentioned it, faulting with a missing symbol map.

The symbol fold now skips any diff whose column the effective projection does not reach, while a rebind that widens the projection refolds from the start of the event file so every symbol value still resolves. Second, the re-derive recovery that rebuilds a view from the applied base table when a needed WAL segment is gone replayed through a cached compiled plan, which was refused whenever the base metadata version had moved — precisely the state produced by the DDL churn that triggers the fault.

The re-derive now recompiles once and retries the replay. Because rebuilding is only safe while the view's referenced columns survive, a shared guard reads the base's applied metadata ahead of both the initial and the recompiled replay and refuses the re-derive when a referenced column was dropped, renamed or retyped, invalidating the view and naming that column instead of silently committing output computed over a new schema.

A non-structural ALTER TABLE base ALTER COLUMN sym SYMBOL CAPACITY N was enough to reach the fault, since the following WAL segment roll deletes and re-links the symbol dictionary and a lagging view could bind a segment whose dictionary was gone. The re-derive is a full rebuild rather than an incremental drain, so recovery costs a one-off rebuild on the refresh worker where the view previously just stopped.

On Windows a covering-index read racing the writer could map the .pci cover-info file past its end and fail with errno 8, because the writer temporarily grew the small file to the data-index append page and truncated it back on close, letting a reader observe the larger length and map after the file had shrunk.

This fix maps .pci at a page-aligned size derived from the larger of the payload and the existing file and parks the append pointer there, so the physical size is monotonic non-decreasing for the life of the file and a reader can never map across a shrink; a larger existing file is preserved rather than shrunk.

On adjacent paths now owned by the same method, the .pci header is rewritten only when it is absent, shorter than the payload, or its magic, count or covered-column indices disagree with the live configuration, so corruption is repaired and later reads can resolve covers; sync() now fsyncs .pv, each .pcN and .pci before .pk, so a durable chain head can no longer sit over cover bytes that were never flushed; and a failure to read the length of an existing .pci is now reported instead of being treated as a new file, which could reopen it at size zero.

Under SYNC and ASYNC commit modes each covering commit issues up to one additional msync per covered column plus one, and the change is inert under the default NOSYNC.

A client speaking a non-Influx Line Protocol binary protocol on the Influx Line Protocol TCP port — a port scanner, for instance — made the server log an unhandled critical error with a full stack trace, because the elliptic-curve authenticator converted raw key-id bytes to a string eagerly and invalid UTF-8 threw a CairoException that the authentication handler did not catch.

Nothing on that path closed the connection, so every bad connection permanently leaked a file descriptor, its receive buffer and one of the 256 default connection slots, and incremented the unhandled_errors counter exported to Prometheus, which pins /status to HTTP 500 for the lifetime of the process when http.pessimistic.health.check=true.

This fix validates the key id as UTF-8 before converting it, so invalid input takes the same path as an unknown key: one log line, then a disconnect. Key-id bytes are now rendered with hex-escaping in logs, so control characters supplied by an unauthenticated peer can no longer be written raw. The authentication handler also catches CairoException, which closes a second instance of the same bug where a signature line that is not valid base64 stranded the connection, while preserving the original severity and errno.

Finally, both the authenticator call and the security context factory call catch Throwable, logging it as critical, counting it as an unhandled error and disconnecting, so nothing escaping a pluggable authenticator can strand a connection. Well-behaved clients are unaffected; the malformed-base64 signature path now produces a real disconnect where the connection was previously stranded, and a CairoException from the authenticator is still logged but no longer moves the unhandled-error metric. There is no configuration or protocol change.

This fix tightens an internal memory bounds check so that invalid writes fail safely instead of corrupting memory. The issue was found internally and no production workload is known to trigger it. There are no SQL, API or configuration changes.

Closing a posting index writer trimmed the .pk key file to that instance's cached high-water mark, but more than one writer instance can be open on the same file — the O3 copy path opens its own alongside the table writer's indexer. When the other instance extended the chain in between, the trim lopped off the tail of the just-published chain entry, typically its last generation-directory slot.

Those bytes read back as zeros, so the generation's seal transaction regressed behind a real transaction: queries failed with an AssertionError carrying no diagnostic on assertion-enabled servers, and silently returned fewer rows from POSTING index scans otherwise, while genuinely abandoned generations were never trimmed on recovery.

This fix never trims below the region limit published in the chain header, the authoritative live high-water written under the header seqlock by whichever instance extended the region last. Along the way it clamps a generation slot's seal transaction up to its predecessor so a later generation can never become visible earlier than an earlier one, validates generation-directory monotonicity before publishing and raises a diagnostic CairoException naming the writer, entry offset and generation counts instead of an assertion, re-validates the entry seqlock so an entry rewritten in place with a smaller generation count cannot mix two incarnations, moves the reader's monotonicity check out of the window where torn reads are legal so a concurrent publish retries instead of failing, and makes close non-throwing so a cleanup failure can no longer skip subsequent frees and strand the table lock.

A .pk already damaged by an earlier build does not self-heal: depending on the entry it either fails reads and suspends the WAL table on the next extending commit, or reads back as an empty generation, and the remedy in both cases is to rebuild the index:

REINDEX TABLE <table> COLUMN <column> LOCK EXCLUSIVE;

This fix removes a race in LiveViewRefreshJob.scanForLaggingViews() where an idle fallback scan could durably invalidate a healthy live view while another worker was refreshing a new base-table commit. The guard that detects a view whose processed sequencer transaction is ahead of its base table sampled the base sequencer head before the volatile view watermark, so a refresh publishing the next base transaction between the two reads produced an impossible old-base/new-view pair, for example (view=1, base=0), and persisted a false view is ahead of base table invalidation.

The view watermark is now read and retained first, followed by the monotonic base sequencer head, and both the comparison and the diagnostic log use the same retained values. Because a refresh publishes the watermark only after consuming the corresponding base sequencer transaction, a newer watermark can no longer be paired with an older base head, and the fix adds no hot-path lock. Genuine restored or replicated ahead states still take the existing invalidation path.

A REPLACE_RANGE WAL commit, used by materialized view refreshes and range-replace inserts, that removed the table's last partition moved the writer's maxTimestamp back to the new last partition but left partitionTimestampHi pointing at the removed partition, since the replace path only ever advanced it via Math.max and never lowered it.

finishO3Commit normally re-syncs partitionTimestampHi by re-opening the new last partition, but that re-open is skipped when the new last partition is Parquet, so the next non-replace commit applied by the same TableWriter instance tripped the partition-timestamp consistency assertion in processWalCommit and suspended the table.

This fix re-derives partitionTimestampHi from the final maxTimestamp in the partition-removal branch of o3ConsumePartitionUpdateSink after partition sizes are updated, covering the Parquet last-partition case that the re-open path misses. A native last partition already received the same value through the re-open, so its behaviour is unchanged, and the new logic runs only for replace commits that removed or trimmed partitions.

Decorrelation turns a scalar-aggregate lateral body into GROUP BY plus LEFT JOIN, which loses the empty-group row, and the previous compensation recognised only bare count() projections. As a result unmatched rows returned NULL for count(*) + 2, CASE WHEN count() = 0 THEN 7 ELSE count() END, count_distinct(x) and approx_count_distinct(x) bodies, and for sibling columns of a count, while WHERE sub.cnt = 0 filtered out the very rows it was meant to select.

This fix builds a compensation template for any projection containing a zero-on-empty aggregate (count, count_distinct, approx_count_distinct), extracting aggregate leaves into hidden carrier columns and wrapping only zero-on-empty leaves in coalesce(x, 0), so count(*) + 2 returns 2 while count(*) + sum(v) correctly stays NULL; constants, outer references and bind variables now carry their value onto the compensated row, and WHERE terms over compensated columns are hoisted above the null-extension boundary so they see 0 rather than NULL.

Keyed bodies are no longer treated as scalar, so an implicit group-by key, a SAMPLE BY body, or a WINDOW JOIN/HORIZON JOIN body correctly returns NULL instead of a fabricated 0, and CROSS JOIN LATERAL/INNER JOIN LATERAL over a scalar aggregate body are promoted to LEFT OUTER so outer rows are no longer dropped.

PIVOT empty cells for approx_count_distinct now default to 0 instead of NULL, count(*) parses in any expression position so coalesce(count(*), 5) and count(*) + count(*) no longer fail with too few arguments for '*', statement rewrites now walk OVER() sub-expressions (also repairing :: casts and multi-WHEN CASE inside a window specification), and a negative LIMIT reaching a lateral body through a bind variable or outer column now fails with negative LIMIT is not supported in a correlated lateral sub-query instead of silently emptying the body. For example:

SELECT o.id, s.c
FROM orders o
LEFT JOIN LATERAL (
  SELECT count(*) + 2 AS c FROM trades t WHERE t.id = o.id
) s;

now returns 2 for unmatched rows rather than NULL. Window-function bodies such as count(*) OVER () are deliberately left uncompensated, since a window function produces no row over an empty input.

OrderedMap compresses each hash-table slot's heap offset into an unsigned 32-bit int with a +1 bias, but eight slot-emptiness scans used signed comparisons, so above roughly 16GB of map heap live entries were read as empty: the destination side of a shard merge wrote duplicate groups, while the source side silently dropped whole groups from a parallel GROUP BY.

All scans now route through a single unsigned predicate. Five budgeted structures (OrderedMap, LongChain, AbstractRedBlackTree, LongTreeChain, LimitedSizeLongTreeChain) previously rejected a growth step whenever one doubling overshot the configured ceiling, producing memory-limit errors well below it, and now clamp to the ceiling instead, with the tradeoff that a runaway query can hold up to twice as much native memory before being stopped.

This fix also corrects a cached ORDER BY ... LIMIT $1 returning wrong rows when the bind value flipped sign with cairo.sql.orderby.sort.enabled=false, since the cursor never re-derived its first-N early-stop flag per execution; an ArrayIndexOutOfBoundsException when a window ORDER BY had more terms than the model's, now handled by a single shared order-dismissal check; allocation-ordering and lifecycle defects in the multipart boundary augmenter, plus native memory leaks in HttpHeaderParser, HttpConnectionContext and the platform HttpClient constructors when a later allocation failed, with the same rollback applied to the Influx Line Protocol HTTP client fork; and initial heap pages that exceeded their compressed-offset ceilings and handed out truncated offsets.

Budget floors were added for LongChain and SingleRecordSink, and overflow messages now name the owning feature (ASOF join, RANK() window function, DENSE_RANK() window function) and the configuration key to raise. Configuration validation is stricter: cairo.sql.small.map.page.size and cairo.sql.join.metadata.page.size reject values below 4, cairo.sql.hash.join.light.value.page.size rejects values below 12, cairo.sql.small.map.page.size and cairo.sql.sort.key.page.size reject values above 34,359,738,352, and cairo.sql.sort.light.value.page.size rejects values above 17,179,869,176.

Additionally, top-K eviction now tracks the extreme node incrementally instead of re-walking the tree spine on every accepted insert, and hot-loop slot reads in OrderedMap and grandparent lookups in AbstractRedBlackTree.fixInsert() were reduced to single accesses.

This fix prevents squashSplitPartitions from destroying the tail of a variable-size column (BINARY, STRING, VARCHAR) in the partition it squashes into. The squash appends into the target partition through the frame's own file descriptors, so when that target is the partition the writer still holds open, the writer's column append memories keep their pre-squash positions and describe a shorter file than what is on disk; the stale append memory then trims the file back on close and a later memory re-extends it zero-filled, cutting the last value's length prefix in half.

With assertions disabled this produced silently wrong query results, and otherwise surfaced as binary is outside of file boundary or an unsafe memory access fault. The writer can end up holding a non-last partition open because openLastPartition() no-ops when the last partition is Parquet, which pins the writer to an earlier native partition.

When the squash target is the writer's open partition, the stale view is now dropped by closing without truncating and re-opening the target so the writer resumes from sizes that match disk, with partitionTimestampHi saved and restored and both arms running under a single distress guard. Both close calls in squashSplitPartitions now drain the posting-index seal-purge outbox first, so superseded .pv and .pc files are published for purge rather than leaked on disk.

This fix also hardens the POSTING index: close() no longer sizes a mapping up just before releasing it (avoiding a wasted append-page allocation) and swallows a failure of its own log record so the non-throwing close contract holds; the gen-directory TXN_AT_SEAL clamp is now guarded against brand-new entries, a MAX_VALUE regression on an in-place extend throws, and six call sites that previously fell back to a 0 tag now arm the correct transaction first.

The per-publish checkGenDirMonotonic scan is replaced by an assertion-only check of the slot just written, so production builds without assertions no longer detect an at-rest gen-directory regression on the writer side. On the reader side, structural checks now reject all-zero and partially zeroed generation slots that the tag sequence alone could not see, and the resulting CairoException names the column and the recovery step, for example posting index is corrupt, rebuild it with REINDEX TABLE <table> COLUMN <column> LOCK EXCLUSIVE; queries that previously returned a silently short scan over a damaged index now raise this error instead.

This fix allows SHOW CREATE DATABASE to be used as a parenthesized query source in FROM, CTE, and JOIN contexts, while filters and INCLUDE (...) / EXCLUDE (...) clauses keep their existing top-level behaviour. The parser previously read clause delimiters with helpers that, in subquery mode, consumed a closing ) while treating it as the enclosing subquery terminator, so the outer parser lost either the SHOW subquery delimiter or the category-list delimiter.

Optional-clause lookahead is now performed without consuming the token, the enclosing delimiter is returned to the outer parser, and the category list's own closing delimiter is read locally. Valid top-level statements are unchanged; for malformed input that closes a valid category list but omits the enclosing subquery delimiter, the parser now reports the more specific outer error ')' expected instead of ',' or ')' expected.

This fix makes current_user() and session_user() report the principal that actually authenticated. Both functions previously returned the hardcoded default admin, because the allow-all and read-only security contexts used when per-user authorization is not enforced reported a fixed principal, so the Web Console displayed admin for every user, including a configured http.user or a PostgreSQL Wire Protocol user.

AllowAllSecurityContext and ReadOnlySecurityContext now carry a principal and expose a derivation method that returns a context reporting the authenticated user, and the security context factories pass the authenticated principal through it. Anonymous requests allocate nothing, since the derivation returns the singleton unchanged for a null, empty, or default-matching principal.

Because the HTTP path re-derives the security context on every request while PostgreSQL Wire Protocol and Influx Line Protocol derive once per connection, derived contexts are cached per principal in a concurrent map that is softly bounded at 256 principals; past that bound an unseen principal degrades to allocating per call rather than growing the map without limit.

The derivation is final and constructs instances through an overridable factory method, with an assertion rejecting subclasses that do not override it so a restrictive context can never be silently downgraded into a permissive one; the deny-all and materialized-view refresh contexts return themselves and are never re-derived.

The transient principal is copied before it is retained. current_user() and session_user() are now runtime constants that snapshot the principal in init() rather than reading the security context once per row, so a 1000-row query drops from 1004 to 5 security-context reads for current_user() and from 1000 to 1 for session_user(); results are unchanged because the security context cannot change mid-cursor and init() runs on every getCursor().

This fix prevents a POSTING index writer from dereferencing a closed value-file (.pv) mapping during rollback after an I/O failure, which previously produced an assertion failure, a null facade access, or a native-memory crash depending on the path. Two fault states are covered: when growing .pv during flushAllPending() fails to remap, the value memory is unmapped while the pending batch remains, so a subsequent rollbackValues() re-entered the flush and appended through closed memory; and when truncate() fails to open the replacement .pv, the writer retains generation metadata while the value memory stays closed, so a later rollbackValues() could reach reencodeAllGenerations() where generation zero resolved to native address zero and terminated the JVM with SIGSEGV.

The sparse and dense flush paths now reject non-empty work when the value memory is closed, reencodeAllGenerations() rejects a closed value memory when generations exist, and all guards raise a CairoException before any scratch allocation or posting-index mutation.

In addition, MemoryCMARWImpl.close() now clears lim and appendAddress after releasing the mapping, since the stale bounds could let checkAndExtend() accept an address without remapping and turn post-close use into an access through unmapped memory; reopening the instance reconstructs both bounds.

Table-level recovery is unchanged: the caller still distresses and discards the affected writer and the on-disk chain is recovered on the next open, with the invalid memory access replaced by a controlled exception, and the close-on-remap-failure policy and the ordering of truncate()'s close and replacement open are untouched.

This fix stops ALTER TABLE ... ALTER COLUMN ... TYPE from killing the JVM with a native SIGBUS when disk space is low. The destination column file was sized with ftruncate(), which only sets the logical file length and does not reserve real disk blocks, so a later native write into an unbacked page faulted with a signal that cannot be caught from Java or JNI.

The conversion now reserves space through TableUtils.allocateDiskSpace() (posix_fallocate) before the file is mapped for writing, matching every other writable memory-mapped call site in the codebase, so a disk-space shortfall surfaces as a catchable CairoException and the statement fails with a normal error instead.

This fix ensures the OIDC state parameter is verified whenever the server sets acl.oidc.state.required. Previously setupOAuth2 compared the state parameter only when a state value already sat in localStorage, so a browser that never started a login skipped the check and exchanged any ?code= sent to it.

A missing or mismatched state now results in logout({ promptForLogin: true }), and OAUTH_STATE is cleared on every code path rather than only inside the old branch.

This fix renames all @questdb/mcp-bridge occurrences to the new package name @questdb/mcp-server-questdb, and replaces MCP bridge wording with MCP server. It also bumps the expected MCP version to 0.4.0.