From 4a00153329e19acf2ac13ae9c8613d2146353a1f Mon Sep 17 00:00:00 2001
From: "riseproject-dev[bot]"
 <330740410+riseproject-dev[bot]@users.noreply.github.com>
Date: Fri, 2 Oct 2026 08:03:01 +0000
Subject: [PATCH 1/3] ladybug: Add versions 0.20.0, 0.20.1, 0.20.2, 0.20.3,
 0.20.4, 0.21.0, 0.21.1, 0.21.2

Signed-off-by: riseproject-dev[bot] <330740410+riseproject-dev[bot]@users.noreply.github.com>
---
 docs/packages/ladybug.yaml | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/docs/packages/ladybug.yaml b/docs/packages/ladybug.yaml
index c06ea16c00b..030dd4b6e22 100644
--- a/docs/packages/ladybug.yaml
+++ b/docs/packages/ladybug.yaml
@@ -23,3 +23,11 @@ versions:
   - filename: ladybug-0.19.1-cp314-cp314t-manylinux_2_39_riscv64.whl
     sha256: 6f365ce0a83d6fcd6b1abc76e78f34759de07a1a7b823f4f3e4119b2f6382537
     requires-python: <3.15,>=3.10
+- version: 0.20.0
+- version: 0.20.1
+- version: 0.20.2
+- version: 0.20.3
+- version: 0.20.4
+- version: 0.21.0
+- version: 0.21.1
+- version: 0.21.2

From 6c61fd8a8a1df7e6b3f37c496fdcff55f7cf3d17 Mon Sep 17 00:00:00 2001
From: Ludovic Henry <git@ludovic.dev>
Date: Fri, 2 Oct 2026 08:28:28 +0000
Subject: [PATCH 2/3] ladybug: restore the riscv64 patches and
 SIGSEGV/pyarrow_scan fixes the bot's version bump dropped

The nightly-upgrade bot force-pushes this branch from main plus its own
docs/packages/ladybug.yaml bump every time check_versions.py finds a
newer upstream release while the PR is still open, which silently
discards every commit this branch carried that the bot doesn't know
about - in this case all of it: the base riscv64-enablement patches
for 0.20.0-0.21.1 (VMRegion reservation size, the interrupt-repeat
test fix, and the riscv64 platform-extension report), 0.20.0's
SIGSEGV backport, and 0.20.2's empty-pyarrow-scan backport. Restoring
all three, plus carrying the same base patch set forward into the
newly added 0.21.2 since it needs it for the same reason 0.20.0-0.21.1
originally did.
---
 .github/workflows/build-ladybug.yml           |  9 ++
 ...e-VMRegion-reservation-until-it-fits.patch | 48 ++++++++++
 ...-the-interrupt-until-the-query-stops.patch | 41 +++++++++
 ...n-report-riscv64-as-its-own-platform.patch | 33 +++++++
 ...-clear-early-return-for-empty-schema.patch | 47 ++++++++++
 ...t-clobber-live-queryresults-on-reuse.patch | 91 +++++++++++++++++++
 ...e-VMRegion-reservation-until-it-fits.patch | 48 ++++++++++
 ...-the-interrupt-until-the-query-stops.patch | 41 +++++++++
 ...n-report-riscv64-as-its-own-platform.patch | 33 +++++++
 ...e-VMRegion-reservation-until-it-fits.patch | 48 ++++++++++
 ...-the-interrupt-until-the-query-stops.patch | 41 +++++++++
 ...n-report-riscv64-as-its-own-platform.patch | 33 +++++++
 ...can-rewind-the-chunk-cursor-on-reuse.patch | 73 +++++++++++++++
 ...e-VMRegion-reservation-until-it-fits.patch | 48 ++++++++++
 ...-the-interrupt-until-the-query-stops.patch | 41 +++++++++
 ...n-report-riscv64-as-its-own-platform.patch | 33 +++++++
 ...e-VMRegion-reservation-until-it-fits.patch | 48 ++++++++++
 ...-the-interrupt-until-the-query-stops.patch | 41 +++++++++
 ...n-report-riscv64-as-its-own-platform.patch | 33 +++++++
 ...e-VMRegion-reservation-until-it-fits.patch | 48 ++++++++++
 ...-the-interrupt-until-the-query-stops.patch | 41 +++++++++
 ...n-report-riscv64-as-its-own-platform.patch | 33 +++++++
 ...e-VMRegion-reservation-until-it-fits.patch | 48 ++++++++++
 ...-the-interrupt-until-the-query-stops.patch | 41 +++++++++
 ...n-report-riscv64-as-its-own-platform.patch | 33 +++++++
 ...e-VMRegion-reservation-until-it-fits.patch | 48 ++++++++++
 ...-the-interrupt-until-the-query-stops.patch | 41 +++++++++
 ...n-report-riscv64-as-its-own-platform.patch | 33 +++++++
 28 files changed, 1196 insertions(+)
 create mode 100644 patches/ladybug/0.20.0/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
 create mode 100644 patches/ladybug/0.20.0/0002-test-repeat-the-interrupt-until-the-query-stops.patch
 create mode 100644 patches/ladybug/0.20.0/0003-extension-report-riscv64-as-its-own-platform.patch
 create mode 100644 patches/ladybug/0.20.0/0004-factorized_table-clear-early-return-for-empty-schema.patch
 create mode 100644 patches/ladybug/0.20.0/0005-result_collector-dont-clobber-live-queryresults-on-reuse.patch
 create mode 100644 patches/ladybug/0.20.1/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
 create mode 100644 patches/ladybug/0.20.1/0002-test-repeat-the-interrupt-until-the-query-stops.patch
 create mode 100644 patches/ladybug/0.20.1/0003-extension-report-riscv64-as-its-own-platform.patch
 create mode 100644 patches/ladybug/0.20.2/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
 create mode 100644 patches/ladybug/0.20.2/0002-test-repeat-the-interrupt-until-the-query-stops.patch
 create mode 100644 patches/ladybug/0.20.2/0003-extension-report-riscv64-as-its-own-platform.patch
 create mode 100644 patches/ladybug/0.20.2/0004-pyarrow_scan-rewind-the-chunk-cursor-on-reuse.patch
 create mode 100644 patches/ladybug/0.20.3/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
 create mode 100644 patches/ladybug/0.20.3/0002-test-repeat-the-interrupt-until-the-query-stops.patch
 create mode 100644 patches/ladybug/0.20.3/0003-extension-report-riscv64-as-its-own-platform.patch
 create mode 100644 patches/ladybug/0.20.4/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
 create mode 100644 patches/ladybug/0.20.4/0002-test-repeat-the-interrupt-until-the-query-stops.patch
 create mode 100644 patches/ladybug/0.20.4/0003-extension-report-riscv64-as-its-own-platform.patch
 create mode 100644 patches/ladybug/0.21.0/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
 create mode 100644 patches/ladybug/0.21.0/0002-test-repeat-the-interrupt-until-the-query-stops.patch
 create mode 100644 patches/ladybug/0.21.0/0003-extension-report-riscv64-as-its-own-platform.patch
 create mode 100644 patches/ladybug/0.21.1/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
 create mode 100644 patches/ladybug/0.21.1/0002-test-repeat-the-interrupt-until-the-query-stops.patch
 create mode 100644 patches/ladybug/0.21.1/0003-extension-report-riscv64-as-its-own-platform.patch
 create mode 100644 patches/ladybug/0.21.2/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
 create mode 100644 patches/ladybug/0.21.2/0002-test-repeat-the-interrupt-until-the-query-stops.patch
 create mode 100644 patches/ladybug/0.21.2/0003-extension-report-riscv64-as-its-own-platform.patch

diff --git a/.github/workflows/build-ladybug.yml b/.github/workflows/build-ladybug.yml
index 61b985543b5..895f36dedaa 100644
--- a/.github/workflows/build-ladybug.yml
+++ b/.github/workflows/build-ladybug.yml
@@ -66,6 +66,15 @@ jobs:
       - name: Update submodules
         run: git submodule update --init --recursive tools/python_api
 
+      - name: Checkout python-wheels
+        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
+        with:
+          path: python-wheels
+          persist-credentials: false
+
+      - name: Apply Python binding patches
+        run: git apply --exclude='tools/python_api/test/*' --include='tools/python_api/*' python-wheels/patches/ladybug/${{ env.LADYBUG_VERSION }}/*.patch
+
       - uses: astral-sh/setup-uv@20cfd1bf945f4377ade1205e4dbc17946fc9a30d  # v10.0.1
         with:
           python-version: '3.12'
diff --git a/patches/ladybug/0.20.0/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch b/patches/ladybug/0.20.0/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
new file mode 100644
index 00000000000..9c58b6d45f1
--- /dev/null
+++ b/patches/ladybug/0.20.0/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
@@ -0,0 +1,48 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Fri, 25 Sep 2026 00:00:00 +0000
+Subject: [PATCH] storage: shrink the VMRegion reservation until it fits
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+Every Database reserves its buffer-manager region with one mmap of
+max_db_size bytes, and max_db_size defaults to 1 << 43 (8TB). riscv64
+Sv39 gives a process 256GB of user address space (the T-Head C910/C920
+cores the riscv64 runners use only implement Sv39), so the reservation
+fails with ENOMEM and every Database() created with the default
+settings throws "Mmap for size 8796093022208 failed." The same happens
+under a 39-bit VA arm64 kernel, or on x86-64 under
+`ulimit -v 268435456`. Still present in v0.20.4.
+
+On ENOMEM, halve the reservation until it fits. Where the full region
+fits nothing changes; elsewhere the database is capped at the largest
+power-of-two region the address space can hold, the limit
+max_db_size already expresses.
+---
+diff --git a/src/storage/buffer_manager/vm_region.cpp b/src/storage/buffer_manager/vm_region.cpp
+index 429bc61..d102eef 100644
+--- a/src/storage/buffer_manager/vm_region.cpp
++++ b/src/storage/buffer_manager/vm_region.cpp
+@@ -13,6 +13,8 @@
+ #else
+ #include <sys/mman.h>
+ #include <unistd.h>
++
++#include <cerrno>
+ #endif
+ 
+ #include "common/assert.h"
+@@ -61,6 +63,13 @@ VMRegion::VMRegion(PageSizeClass pageSizeClass, uint64_t maxRegionSize) : numFra
+     // backed by any file, and its content are initialized to zero.
+     region = static_cast<uint8_t*>(mmap(NULL, getMaxRegionSize(), PROT_READ | PROT_WRITE,
+         MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1 /* fd */, 0 /* offset */));
++    // The default 8TB region does not fit in a smaller user address space (256GB under riscv64
++    // Sv39, 512GB under a 39-bit VA arm64 kernel), so halve the reservation until it does.
++    while (region == MAP_FAILED && errno == ENOMEM && maxNumFrameGroups > 1) {
++        maxNumFrameGroups /= 2;
++        region = static_cast<uint8_t*>(mmap(NULL, getMaxRegionSize(), PROT_READ | PROT_WRITE,
++            MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1 /* fd */, 0 /* offset */));
++    }
+     if (region == MAP_FAILED) {
+         throw BufferManagerException(
+             "Mmap for size " + std::to_string(getMaxRegionSize()) + " failed.");
diff --git a/patches/ladybug/0.20.0/0002-test-repeat-the-interrupt-until-the-query-stops.patch b/patches/ladybug/0.20.0/0002-test-repeat-the-interrupt-until-the-query-stops.patch
new file mode 100644
index 00000000000..fda78c4815a
--- /dev/null
+++ b/patches/ladybug/0.20.0/0002-test-repeat-the-interrupt-until-the-query-stops.patch
@@ -0,0 +1,41 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Sat, 27 Sep 2026 00:00:00 +0000
+Subject: [PATCH] test: repeat the interrupt until the query stops
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+test_connection_interrupt starts a long query on a thread, sleeps 5s,
+calls conn.interrupt() once and expects the thread to end within 100s.
+Binding folds each RANGE(1, 1000000) into a million-element list
+literal, and ClientContext::executeNoLock() calls resetActiveQuery(),
+which clears the interrupted flag, only once compilation is done. On
+the riscv64 runners compiling the query takes longer than 5s, so the
+interrupt lands during compilation, is wiped, and the query keeps
+running. The fixture teardown's close() then waits on it for about 4
+hours, and the query thread segfaults freeing its FactorizedTable
+after the database is gone. The same loss reproduces on x86-64 with
+upstream's 0.19.1 wheel when the sleep is shorter than the compile.
+Still present on ladybug-python main.
+
+Re-issue the interrupt every second until the thread ends, within the
+same 100s budget. On a fast machine the first interrupt still sticks
+and the test behaves as before.
+---
+diff --git a/tools/python_api/test/test_connection.py b/tools/python_api/test/test_connection.py
+index dcc8ee5..aeb2d54 100644
+--- a/tools/python_api/test/test_connection.py
++++ b/tools/python_api/test/test_connection.py
+@@ -46,6 +46,10 @@ def test_connection_interrupt(conn_db_readwrite: ConnDB) -> None:
+     execute_thread = threading.Thread(target=run_long_query, args=(conn,))
+     execute_thread.start()
+     time.sleep(5)
+-    conn.interrupt()
+-    execute_thread.join(timeout=100)
++    # Compiling this query can outlast the sleep on a slow machine, and the interrupt flag is
++    # cleared when execution starts, so an interrupt sent during compilation is lost; repeat it.
++    deadline = time.monotonic() + 100
++    while execute_thread.is_alive() and time.monotonic() < deadline:
++        conn.interrupt()
++        execute_thread.join(timeout=1)
+     assert not execute_thread.is_alive()
diff --git a/patches/ladybug/0.20.0/0003-extension-report-riscv64-as-its-own-platform.patch b/patches/ladybug/0.20.0/0003-extension-report-riscv64-as-its-own-platform.patch
new file mode 100644
index 00000000000..ba6c25260cc
--- /dev/null
+++ b/patches/ladybug/0.20.0/0003-extension-report-riscv64-as-its-own-platform.patch
@@ -0,0 +1,33 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Sun, 27 Sep 2026 00:00:00 +0000
+Subject: [PATCH] extension: report riscv64 as its own platform
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+getArch() starts from "amd64" and only overrides it for x86 and arm64,
+so on riscv64 getPlatform() returns "linux_amd64". INSTALL then
+downloads the x86-64 build of an extension from
+extension.ladybugdb.com into ~/.lbdb/extension/<ver>/linux_amd64/,
+and LOAD fails with "cannot open shared object file: No such file or
+directory", which is how glibc's dlopen reports an ELF for another
+machine. Seen in test_json.py's INSTALL json; LOAD json on the riscv64
+runners. Still present on main.
+
+Return "riscv64" there, so INSTALL looks for linux_riscv64 builds
+(upstream publishes none yet) and the extension cache is keyed by the
+right platform.
+---
+diff --git a/src/extension/extension.cpp b/src/extension/extension.cpp
+index e87004f..e9e2891 100644
+--- a/src/extension/extension.cpp
++++ b/src/extension/extension.cpp
+@@ -144,6 +144,8 @@ std::string getArch() {
+     arch = "x86";
+ #elif defined(__aarch64__) || defined(__ARM_ARCH_ISA_A64)
+     arch = "arm64";
++#elif defined(__riscv) && __riscv_xlen == 64
++    arch = "riscv64";
+ #endif
+     return arch;
+ }
diff --git a/patches/ladybug/0.20.0/0004-factorized_table-clear-early-return-for-empty-schema.patch b/patches/ladybug/0.20.0/0004-factorized_table-clear-early-return-for-empty-schema.patch
new file mode 100644
index 00000000000..0abbdcd869a
--- /dev/null
+++ b/patches/ladybug/0.20.0/0004-factorized_table-clear-early-return-for-empty-schema.patch
@@ -0,0 +1,47 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Thu, 1 Oct 2026 00:00:00 +0000
+Subject: [PATCH] factorized_table: clear() early-return for empty schema
+
+Upstream-Status: Backport [https://github.com/LadybugDB/ladybug/commit/d09008e75168e2d204b62cbd12029b621631d6f6]
+
+Re-executing the same parameterized write query string (e.g.
+`CREATE (:Log {id: $id, value: $val})`) through the implicit
+prepared-statement cache SIGSEGVs on the second execution. The
+cached-physical-plan fast path calls prepareForReuse(), which reaches
+ResultCollector::prepareForReuse() and FactorizedTable::clear(). For a
+write statement the root ResultCollector's FactorizedTable has an empty
+result schema (writes return no columns), and the constructor skips
+allocating flatTupleBlockCollection / unFlatTupleBlockCollection /
+inMemOverflowBuffer entirely for an empty schema. clear()
+unconditionally dereferenced the null block collection.
+
+Reproduces identically on cp312/cp313/cp314 and cp314t (not a
+free-threading or riscv64 issue): see e.g. the python_api test suite's
+test_blob_parameter.py::test_bytes_param and
+test_datatype.py::test_large_array, both of which loop a parameterized
+CREATE over the same connection. Fixed upstream before 0.20.1.
+---
+ src/processor/result/factorized_table.cpp | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/src/processor/result/factorized_table.cpp b/src/processor/result/factorized_table.cpp
+index cc2fd52..78a41ab 100644
+--- a/src/processor/result/factorized_table.cpp
++++ b/src/processor/result/factorized_table.cpp
+@@ -333,6 +333,13 @@ void FactorizedTable::setNonOverflowColNull(uint8_t* nullBuffer, ft_col_idx_t col
+ }
+
+ void FactorizedTable::clear() {
++    if (tableSchema.isEmpty()) {
++        // Tables with an empty schema (e.g. the root ResultCollector of a CREATE / DDL
++        // statement) never allocate block collections or an overflow buffer; there is
++        // nothing to reset. Mirrors the constructor, which skips allocation entirely for
++        // an empty schema.
++        return;
++    }
+     numTuples = 0;
+     // Reuse the first DataBlock (zeroed) and drop the rest. This skips the
+     // 256KB malloc on the next append while preserving the dense-packing
+--
+2.43.0
diff --git a/patches/ladybug/0.20.0/0005-result_collector-dont-clobber-live-queryresults-on-reuse.patch b/patches/ladybug/0.20.0/0005-result_collector-dont-clobber-live-queryresults-on-reuse.patch
new file mode 100644
index 00000000000..6511e0256cf
--- /dev/null
+++ b/patches/ladybug/0.20.0/0005-result_collector-dont-clobber-live-queryresults-on-reuse.patch
@@ -0,0 +1,91 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Thu, 1 Oct 2026 00:00:00 +0000
+Subject: [PATCH] result_collector: don't clobber live QueryResults on reuse
+
+Upstream-Status: Backport [https://github.com/LadybugDB/ladybug/commit/47443cd683adaf6b34d717cf751ecd6cb22c0869]
+
+The cached-physical-plan fast path clones the template operator tree
+per execution and calls prepareForReuse(). The plan template shares the
+ResultCollectorSharedState (and its FactorizedTable) with every
+executed clone, and prepareForReuse() unconditionally clear()ed that
+table. A QueryResult from a previous execution holds a shared_ptr to
+the same table, so overlapping executions (e.g. AsyncConnection's pool,
+running the same parameterized statement concurrently) corrupted live
+results: queries returned other queries' rows or empty tables.
+
+This is exactly what test_async_connection.py::
+test_async_prepare_and_execute_concurrent hits on 0.20.0 (upstream's own
+commit message cites this same test by name: "asserted [96] == [1]").
+Not free-threading- or riscv64-specific. Fixed upstream before 0.20.1.
+
+The companion simple_table_function.h fix in the same upstream commit
+(resetState() for pandas/polars/arrow table-function rescans) isn't
+known to be exercised by anything failing in this port's test suite on
+0.20.0, but it's included here too since it's part of the same commit
+and trivially small.
+---
+ src/include/function/table/simple_table_function.h |  4 ++++
+ src/include/processor/operator/result_collector.h  |  2 ++
+ src/processor/operator/result_collector.cpp         | 18 +++++++++++++++---
+ 3 files changed, 21 insertions(+), 3 deletions(-)
+
+diff --git a/src/include/function/table/simple_table_function.h b/src/include/function/table/simple_table_function.h
+index 5314b73..32abebc 100644
+--- a/src/include/function/table/simple_table_function.h
++++ b/src/include/function/table/simple_table_function.h
+@@ -39,6 +39,10 @@ public:
+
+     virtual TableFuncMorsel getMorsel();
+
++    // Reset the scan position so a reused physical plan (cached-plan fast path)
++    // rescans from the beginning instead of finding an exhausted morsel cursor.
++    void resetState() override { curRowIdx = 0; }
++
+     common::row_idx_t curRowIdx = 0;
+     common::offset_t maxMorselSize = common::DEFAULT_VECTOR_CAPACITY;
+ };
+diff --git a/src/include/processor/operator/result_collector.h b/src/include/processor/operator/result_collector.h
+index bad840e..1b52db1 100644
+--- a/src/include/processor/operator/result_collector.h
++++ b/src/include/processor/operator/result_collector.h
+@@ -22,6 +22,8 @@ public:
+
+     std::shared_ptr<FactorizedTable> getTable() { return table; }
+
++    void setTable(std::shared_ptr<FactorizedTable> newTable) { table = std::move(newTable); }
++
+ private:
+     std::mutex mtx;
+     std::shared_ptr<FactorizedTable> table;
+diff --git a/src/processor/operator/result_collector.cpp b/src/processor/operator/result_collector.cpp
+index 2685d0f..ee45bef 100644
+--- a/src/processor/operator/result_collector.cpp
++++ b/src/processor/operator/result_collector.cpp
+@@ -58,9 +58,21 @@ void ResultCollector::executeInternal(ExecutionContext* context) {
+ }
+
+ void ResultCollector::prepareForReuse(storage::MemoryManager* memoryManager) {
+-    // Clear the existing result table instead of freeing + re-allocating.
+-    // This keeps the DataBlocks alive so the next execution reuses them.
+-    sharedState->getTable()->clear();
++    auto table = sharedState->getTable();
++    if (table.use_count() <= 1) {
++        // No QueryResult outside this shared state references the table, so we can
++        // keep the DataBlocks alive and reset the bookkeeping (Phase 2 fast path).
++        table->clear();
++    } else {
++        // A previous execution's QueryResult still holds this table (e.g. overlapping
++        // AsyncConnection executions of the same prepared statement on the cached-plan
++        // fast path, which shares one ResultCollectorSharedState with the plan template).
++        // Clearing it would corrupt that live result, so hand this execution a fresh
++        // table with the same schema instead. The old table stays alive until the
++        // QueryResult that references it is destroyed.
++        sharedState->setTable(
++            std::make_shared<FactorizedTable>(memoryManager, info.tableSchema.copy()));
++    }
+     PhysicalOperator::prepareForReuse(memoryManager);
+ }
+
+--
+2.43.0
diff --git a/patches/ladybug/0.20.1/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch b/patches/ladybug/0.20.1/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
new file mode 100644
index 00000000000..9c58b6d45f1
--- /dev/null
+++ b/patches/ladybug/0.20.1/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
@@ -0,0 +1,48 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Fri, 25 Sep 2026 00:00:00 +0000
+Subject: [PATCH] storage: shrink the VMRegion reservation until it fits
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+Every Database reserves its buffer-manager region with one mmap of
+max_db_size bytes, and max_db_size defaults to 1 << 43 (8TB). riscv64
+Sv39 gives a process 256GB of user address space (the T-Head C910/C920
+cores the riscv64 runners use only implement Sv39), so the reservation
+fails with ENOMEM and every Database() created with the default
+settings throws "Mmap for size 8796093022208 failed." The same happens
+under a 39-bit VA arm64 kernel, or on x86-64 under
+`ulimit -v 268435456`. Still present in v0.20.4.
+
+On ENOMEM, halve the reservation until it fits. Where the full region
+fits nothing changes; elsewhere the database is capped at the largest
+power-of-two region the address space can hold, the limit
+max_db_size already expresses.
+---
+diff --git a/src/storage/buffer_manager/vm_region.cpp b/src/storage/buffer_manager/vm_region.cpp
+index 429bc61..d102eef 100644
+--- a/src/storage/buffer_manager/vm_region.cpp
++++ b/src/storage/buffer_manager/vm_region.cpp
+@@ -13,6 +13,8 @@
+ #else
+ #include <sys/mman.h>
+ #include <unistd.h>
++
++#include <cerrno>
+ #endif
+ 
+ #include "common/assert.h"
+@@ -61,6 +63,13 @@ VMRegion::VMRegion(PageSizeClass pageSizeClass, uint64_t maxRegionSize) : numFra
+     // backed by any file, and its content are initialized to zero.
+     region = static_cast<uint8_t*>(mmap(NULL, getMaxRegionSize(), PROT_READ | PROT_WRITE,
+         MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1 /* fd */, 0 /* offset */));
++    // The default 8TB region does not fit in a smaller user address space (256GB under riscv64
++    // Sv39, 512GB under a 39-bit VA arm64 kernel), so halve the reservation until it does.
++    while (region == MAP_FAILED && errno == ENOMEM && maxNumFrameGroups > 1) {
++        maxNumFrameGroups /= 2;
++        region = static_cast<uint8_t*>(mmap(NULL, getMaxRegionSize(), PROT_READ | PROT_WRITE,
++            MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1 /* fd */, 0 /* offset */));
++    }
+     if (region == MAP_FAILED) {
+         throw BufferManagerException(
+             "Mmap for size " + std::to_string(getMaxRegionSize()) + " failed.");
diff --git a/patches/ladybug/0.20.1/0002-test-repeat-the-interrupt-until-the-query-stops.patch b/patches/ladybug/0.20.1/0002-test-repeat-the-interrupt-until-the-query-stops.patch
new file mode 100644
index 00000000000..fda78c4815a
--- /dev/null
+++ b/patches/ladybug/0.20.1/0002-test-repeat-the-interrupt-until-the-query-stops.patch
@@ -0,0 +1,41 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Sat, 27 Sep 2026 00:00:00 +0000
+Subject: [PATCH] test: repeat the interrupt until the query stops
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+test_connection_interrupt starts a long query on a thread, sleeps 5s,
+calls conn.interrupt() once and expects the thread to end within 100s.
+Binding folds each RANGE(1, 1000000) into a million-element list
+literal, and ClientContext::executeNoLock() calls resetActiveQuery(),
+which clears the interrupted flag, only once compilation is done. On
+the riscv64 runners compiling the query takes longer than 5s, so the
+interrupt lands during compilation, is wiped, and the query keeps
+running. The fixture teardown's close() then waits on it for about 4
+hours, and the query thread segfaults freeing its FactorizedTable
+after the database is gone. The same loss reproduces on x86-64 with
+upstream's 0.19.1 wheel when the sleep is shorter than the compile.
+Still present on ladybug-python main.
+
+Re-issue the interrupt every second until the thread ends, within the
+same 100s budget. On a fast machine the first interrupt still sticks
+and the test behaves as before.
+---
+diff --git a/tools/python_api/test/test_connection.py b/tools/python_api/test/test_connection.py
+index dcc8ee5..aeb2d54 100644
+--- a/tools/python_api/test/test_connection.py
++++ b/tools/python_api/test/test_connection.py
+@@ -46,6 +46,10 @@ def test_connection_interrupt(conn_db_readwrite: ConnDB) -> None:
+     execute_thread = threading.Thread(target=run_long_query, args=(conn,))
+     execute_thread.start()
+     time.sleep(5)
+-    conn.interrupt()
+-    execute_thread.join(timeout=100)
++    # Compiling this query can outlast the sleep on a slow machine, and the interrupt flag is
++    # cleared when execution starts, so an interrupt sent during compilation is lost; repeat it.
++    deadline = time.monotonic() + 100
++    while execute_thread.is_alive() and time.monotonic() < deadline:
++        conn.interrupt()
++        execute_thread.join(timeout=1)
+     assert not execute_thread.is_alive()
diff --git a/patches/ladybug/0.20.1/0003-extension-report-riscv64-as-its-own-platform.patch b/patches/ladybug/0.20.1/0003-extension-report-riscv64-as-its-own-platform.patch
new file mode 100644
index 00000000000..ba6c25260cc
--- /dev/null
+++ b/patches/ladybug/0.20.1/0003-extension-report-riscv64-as-its-own-platform.patch
@@ -0,0 +1,33 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Sun, 27 Sep 2026 00:00:00 +0000
+Subject: [PATCH] extension: report riscv64 as its own platform
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+getArch() starts from "amd64" and only overrides it for x86 and arm64,
+so on riscv64 getPlatform() returns "linux_amd64". INSTALL then
+downloads the x86-64 build of an extension from
+extension.ladybugdb.com into ~/.lbdb/extension/<ver>/linux_amd64/,
+and LOAD fails with "cannot open shared object file: No such file or
+directory", which is how glibc's dlopen reports an ELF for another
+machine. Seen in test_json.py's INSTALL json; LOAD json on the riscv64
+runners. Still present on main.
+
+Return "riscv64" there, so INSTALL looks for linux_riscv64 builds
+(upstream publishes none yet) and the extension cache is keyed by the
+right platform.
+---
+diff --git a/src/extension/extension.cpp b/src/extension/extension.cpp
+index e87004f..e9e2891 100644
+--- a/src/extension/extension.cpp
++++ b/src/extension/extension.cpp
+@@ -144,6 +144,8 @@ std::string getArch() {
+     arch = "x86";
+ #elif defined(__aarch64__) || defined(__ARM_ARCH_ISA_A64)
+     arch = "arm64";
++#elif defined(__riscv) && __riscv_xlen == 64
++    arch = "riscv64";
+ #endif
+     return arch;
+ }
diff --git a/patches/ladybug/0.20.2/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch b/patches/ladybug/0.20.2/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
new file mode 100644
index 00000000000..9c58b6d45f1
--- /dev/null
+++ b/patches/ladybug/0.20.2/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
@@ -0,0 +1,48 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Fri, 25 Sep 2026 00:00:00 +0000
+Subject: [PATCH] storage: shrink the VMRegion reservation until it fits
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+Every Database reserves its buffer-manager region with one mmap of
+max_db_size bytes, and max_db_size defaults to 1 << 43 (8TB). riscv64
+Sv39 gives a process 256GB of user address space (the T-Head C910/C920
+cores the riscv64 runners use only implement Sv39), so the reservation
+fails with ENOMEM and every Database() created with the default
+settings throws "Mmap for size 8796093022208 failed." The same happens
+under a 39-bit VA arm64 kernel, or on x86-64 under
+`ulimit -v 268435456`. Still present in v0.20.4.
+
+On ENOMEM, halve the reservation until it fits. Where the full region
+fits nothing changes; elsewhere the database is capped at the largest
+power-of-two region the address space can hold, the limit
+max_db_size already expresses.
+---
+diff --git a/src/storage/buffer_manager/vm_region.cpp b/src/storage/buffer_manager/vm_region.cpp
+index 429bc61..d102eef 100644
+--- a/src/storage/buffer_manager/vm_region.cpp
++++ b/src/storage/buffer_manager/vm_region.cpp
+@@ -13,6 +13,8 @@
+ #else
+ #include <sys/mman.h>
+ #include <unistd.h>
++
++#include <cerrno>
+ #endif
+ 
+ #include "common/assert.h"
+@@ -61,6 +63,13 @@ VMRegion::VMRegion(PageSizeClass pageSizeClass, uint64_t maxRegionSize) : numFra
+     // backed by any file, and its content are initialized to zero.
+     region = static_cast<uint8_t*>(mmap(NULL, getMaxRegionSize(), PROT_READ | PROT_WRITE,
+         MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1 /* fd */, 0 /* offset */));
++    // The default 8TB region does not fit in a smaller user address space (256GB under riscv64
++    // Sv39, 512GB under a 39-bit VA arm64 kernel), so halve the reservation until it does.
++    while (region == MAP_FAILED && errno == ENOMEM && maxNumFrameGroups > 1) {
++        maxNumFrameGroups /= 2;
++        region = static_cast<uint8_t*>(mmap(NULL, getMaxRegionSize(), PROT_READ | PROT_WRITE,
++            MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1 /* fd */, 0 /* offset */));
++    }
+     if (region == MAP_FAILED) {
+         throw BufferManagerException(
+             "Mmap for size " + std::to_string(getMaxRegionSize()) + " failed.");
diff --git a/patches/ladybug/0.20.2/0002-test-repeat-the-interrupt-until-the-query-stops.patch b/patches/ladybug/0.20.2/0002-test-repeat-the-interrupt-until-the-query-stops.patch
new file mode 100644
index 00000000000..fda78c4815a
--- /dev/null
+++ b/patches/ladybug/0.20.2/0002-test-repeat-the-interrupt-until-the-query-stops.patch
@@ -0,0 +1,41 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Sat, 27 Sep 2026 00:00:00 +0000
+Subject: [PATCH] test: repeat the interrupt until the query stops
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+test_connection_interrupt starts a long query on a thread, sleeps 5s,
+calls conn.interrupt() once and expects the thread to end within 100s.
+Binding folds each RANGE(1, 1000000) into a million-element list
+literal, and ClientContext::executeNoLock() calls resetActiveQuery(),
+which clears the interrupted flag, only once compilation is done. On
+the riscv64 runners compiling the query takes longer than 5s, so the
+interrupt lands during compilation, is wiped, and the query keeps
+running. The fixture teardown's close() then waits on it for about 4
+hours, and the query thread segfaults freeing its FactorizedTable
+after the database is gone. The same loss reproduces on x86-64 with
+upstream's 0.19.1 wheel when the sleep is shorter than the compile.
+Still present on ladybug-python main.
+
+Re-issue the interrupt every second until the thread ends, within the
+same 100s budget. On a fast machine the first interrupt still sticks
+and the test behaves as before.
+---
+diff --git a/tools/python_api/test/test_connection.py b/tools/python_api/test/test_connection.py
+index dcc8ee5..aeb2d54 100644
+--- a/tools/python_api/test/test_connection.py
++++ b/tools/python_api/test/test_connection.py
+@@ -46,6 +46,10 @@ def test_connection_interrupt(conn_db_readwrite: ConnDB) -> None:
+     execute_thread = threading.Thread(target=run_long_query, args=(conn,))
+     execute_thread.start()
+     time.sleep(5)
+-    conn.interrupt()
+-    execute_thread.join(timeout=100)
++    # Compiling this query can outlast the sleep on a slow machine, and the interrupt flag is
++    # cleared when execution starts, so an interrupt sent during compilation is lost; repeat it.
++    deadline = time.monotonic() + 100
++    while execute_thread.is_alive() and time.monotonic() < deadline:
++        conn.interrupt()
++        execute_thread.join(timeout=1)
+     assert not execute_thread.is_alive()
diff --git a/patches/ladybug/0.20.2/0003-extension-report-riscv64-as-its-own-platform.patch b/patches/ladybug/0.20.2/0003-extension-report-riscv64-as-its-own-platform.patch
new file mode 100644
index 00000000000..ba6c25260cc
--- /dev/null
+++ b/patches/ladybug/0.20.2/0003-extension-report-riscv64-as-its-own-platform.patch
@@ -0,0 +1,33 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Sun, 27 Sep 2026 00:00:00 +0000
+Subject: [PATCH] extension: report riscv64 as its own platform
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+getArch() starts from "amd64" and only overrides it for x86 and arm64,
+so on riscv64 getPlatform() returns "linux_amd64". INSTALL then
+downloads the x86-64 build of an extension from
+extension.ladybugdb.com into ~/.lbdb/extension/<ver>/linux_amd64/,
+and LOAD fails with "cannot open shared object file: No such file or
+directory", which is how glibc's dlopen reports an ELF for another
+machine. Seen in test_json.py's INSTALL json; LOAD json on the riscv64
+runners. Still present on main.
+
+Return "riscv64" there, so INSTALL looks for linux_riscv64 builds
+(upstream publishes none yet) and the extension cache is keyed by the
+right platform.
+---
+diff --git a/src/extension/extension.cpp b/src/extension/extension.cpp
+index e87004f..e9e2891 100644
+--- a/src/extension/extension.cpp
++++ b/src/extension/extension.cpp
+@@ -144,6 +144,8 @@ std::string getArch() {
+     arch = "x86";
+ #elif defined(__aarch64__) || defined(__ARM_ARCH_ISA_A64)
+     arch = "arm64";
++#elif defined(__riscv) && __riscv_xlen == 64
++    arch = "riscv64";
+ #endif
+     return arch;
+ }
diff --git a/patches/ladybug/0.20.2/0004-pyarrow_scan-rewind-the-chunk-cursor-on-reuse.patch b/patches/ladybug/0.20.2/0004-pyarrow_scan-rewind-the-chunk-cursor-on-reuse.patch
new file mode 100644
index 00000000000..46c66d1200e
--- /dev/null
+++ b/patches/ladybug/0.20.2/0004-pyarrow_scan-rewind-the-chunk-cursor-on-reuse.patch
@@ -0,0 +1,73 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Fri, 2 Oct 2026 00:00:00 +0000
+Subject: [PATCH] pyarrow_scan: rewind the chunk cursor on reuse
+
+Upstream-Status: Backport [https://github.com/LadybugDB/ladybug-python/commit/dd285cee422635afa1c5d08b440958769e355f7e]
+
+Re-executing the same prepared statement that scans a pandas/pyarrow
+object on one connection returns 0 rows on every execution after the
+first. With the physical-plan cache, the cached operator tree is cloned
+through TableFunctionCall::copy(), which shares one TableFuncSharedState
+between the template and its copies. The first execution advances
+PyArrowTableScanSharedState::currentChunk to the end of the chunk list,
+and since the shared state kept the base-class no-op resetState(),
+TableFunctionCall::prepareForReuse() never rewinds it.
+
+0.20.2 is the only affected release in this range: its core change for
+upstream #877 (96a4b0805, OrderByScan/TableFunctionCall copy() keeping
+their children) makes a re-executed ORDER BY plan re-run its scan
+pipeline instead of serving the previous execution's sorted rows, which
+exposes the stale cursor. 0.20.3 picks this fix up through its
+tools/python_api submodule bump (01260488f).
+
+test_scan_pandas_pyarrow.py::test_pyarrow_primitive hits it on every
+interpreter, not only on riscv64: Connection.execute() rewrites
+`LOAD FROM df ...` to `LOAD FROM $df ...` with {"df": df}, so the
+helper's second, explicitly parameterized query is a re-execution of the
+first one's cached statement and comes back empty. The upstream commit's
+regression test is carried along.
+---
+ tools/python_api/src_cpp/include/pyarrow/pyarrow_scan.h |  5 +++++
+ tools/python_api/test/test_scan_pandas_pyarrow.py       | 12 ++++++++++++
+ 2 files changed, 17 insertions(+)
+
+diff --git a/tools/python_api/src_cpp/include/pyarrow/pyarrow_scan.h b/tools/python_api/src_cpp/include/pyarrow/pyarrow_scan.h
+index 7e0ef4a..e4dbec9 100644
+--- a/tools/python_api/src_cpp/include/pyarrow/pyarrow_scan.h
++++ b/tools/python_api/src_cpp/include/pyarrow/pyarrow_scan.h
+@@ -26,6 +26,11 @@ struct PyArrowTableScanSharedState final : public function::TableFuncSharedState
+         : TableFuncSharedState{numRows}, chunks{std::move(chunks)}, currentChunk{0} {}
+
+     ArrowArrayWrapper* getNextChunk();
++
++    // TableFunctionCall::copy() (used by the physical-plan cache on prepared
++    // statement re-execution) shares the same sharedState instance, so the
++    // chunk cursor must be rewound here or a re-executed scan yields 0 rows.
++    void resetState() override { currentChunk = 0; }
+ };
+
+ struct PyArrowTableScanFunctionData final : public function::TableFuncBindData {
+diff --git a/tools/python_api/test/test_scan_pandas_pyarrow.py b/tools/python_api/test/test_scan_pandas_pyarrow.py
+index 539f356..d18568e 100644
+--- a/tools/python_api/test/test_scan_pandas_pyarrow.py
++++ b/tools/python_api/test/test_scan_pandas_pyarrow.py
+@@ -141,6 +141,18 @@ def test_pyarrow_primitive(conn_db_empty: ConnDB) -> None:
+             pyarrow_test_helper(establish_connection, sf, thread)
+
+
++def test_pyarrow_scan_repeated_execution(conn_db_in_mem: ConnDB) -> None:
++    # Regression test: re-executing the same (implicitly cached) prepared
++    # statement that scans a python object returned 0 rows on the second run.
++    # The cached physical plan shares the scan's shared state, whose chunk
++    # cursor was never rewound between executions.
++    conn, _ = conn_db_in_mem
++    df = pd.DataFrame({"a": pd.Series([1, 2, 3, None], dtype="int32[pyarrow]")})
++    for _ in range(3):
++        result = conn.execute("LOAD FROM df RETURN count(*)")
++        assert result.get_next()[0] == 4
++
++
+ def test_pyarrow_time(conn_db_readonly: ConnDB) -> None:
+     conn, _ = conn_db_readonly
+     col1 = pa.array([1000123, 2000123, 3000123], type=pa.duration("s"))
diff --git a/patches/ladybug/0.20.3/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch b/patches/ladybug/0.20.3/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
new file mode 100644
index 00000000000..9c58b6d45f1
--- /dev/null
+++ b/patches/ladybug/0.20.3/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
@@ -0,0 +1,48 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Fri, 25 Sep 2026 00:00:00 +0000
+Subject: [PATCH] storage: shrink the VMRegion reservation until it fits
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+Every Database reserves its buffer-manager region with one mmap of
+max_db_size bytes, and max_db_size defaults to 1 << 43 (8TB). riscv64
+Sv39 gives a process 256GB of user address space (the T-Head C910/C920
+cores the riscv64 runners use only implement Sv39), so the reservation
+fails with ENOMEM and every Database() created with the default
+settings throws "Mmap for size 8796093022208 failed." The same happens
+under a 39-bit VA arm64 kernel, or on x86-64 under
+`ulimit -v 268435456`. Still present in v0.20.4.
+
+On ENOMEM, halve the reservation until it fits. Where the full region
+fits nothing changes; elsewhere the database is capped at the largest
+power-of-two region the address space can hold, the limit
+max_db_size already expresses.
+---
+diff --git a/src/storage/buffer_manager/vm_region.cpp b/src/storage/buffer_manager/vm_region.cpp
+index 429bc61..d102eef 100644
+--- a/src/storage/buffer_manager/vm_region.cpp
++++ b/src/storage/buffer_manager/vm_region.cpp
+@@ -13,6 +13,8 @@
+ #else
+ #include <sys/mman.h>
+ #include <unistd.h>
++
++#include <cerrno>
+ #endif
+ 
+ #include "common/assert.h"
+@@ -61,6 +63,13 @@ VMRegion::VMRegion(PageSizeClass pageSizeClass, uint64_t maxRegionSize) : numFra
+     // backed by any file, and its content are initialized to zero.
+     region = static_cast<uint8_t*>(mmap(NULL, getMaxRegionSize(), PROT_READ | PROT_WRITE,
+         MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1 /* fd */, 0 /* offset */));
++    // The default 8TB region does not fit in a smaller user address space (256GB under riscv64
++    // Sv39, 512GB under a 39-bit VA arm64 kernel), so halve the reservation until it does.
++    while (region == MAP_FAILED && errno == ENOMEM && maxNumFrameGroups > 1) {
++        maxNumFrameGroups /= 2;
++        region = static_cast<uint8_t*>(mmap(NULL, getMaxRegionSize(), PROT_READ | PROT_WRITE,
++            MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1 /* fd */, 0 /* offset */));
++    }
+     if (region == MAP_FAILED) {
+         throw BufferManagerException(
+             "Mmap for size " + std::to_string(getMaxRegionSize()) + " failed.");
diff --git a/patches/ladybug/0.20.3/0002-test-repeat-the-interrupt-until-the-query-stops.patch b/patches/ladybug/0.20.3/0002-test-repeat-the-interrupt-until-the-query-stops.patch
new file mode 100644
index 00000000000..fda78c4815a
--- /dev/null
+++ b/patches/ladybug/0.20.3/0002-test-repeat-the-interrupt-until-the-query-stops.patch
@@ -0,0 +1,41 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Sat, 27 Sep 2026 00:00:00 +0000
+Subject: [PATCH] test: repeat the interrupt until the query stops
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+test_connection_interrupt starts a long query on a thread, sleeps 5s,
+calls conn.interrupt() once and expects the thread to end within 100s.
+Binding folds each RANGE(1, 1000000) into a million-element list
+literal, and ClientContext::executeNoLock() calls resetActiveQuery(),
+which clears the interrupted flag, only once compilation is done. On
+the riscv64 runners compiling the query takes longer than 5s, so the
+interrupt lands during compilation, is wiped, and the query keeps
+running. The fixture teardown's close() then waits on it for about 4
+hours, and the query thread segfaults freeing its FactorizedTable
+after the database is gone. The same loss reproduces on x86-64 with
+upstream's 0.19.1 wheel when the sleep is shorter than the compile.
+Still present on ladybug-python main.
+
+Re-issue the interrupt every second until the thread ends, within the
+same 100s budget. On a fast machine the first interrupt still sticks
+and the test behaves as before.
+---
+diff --git a/tools/python_api/test/test_connection.py b/tools/python_api/test/test_connection.py
+index dcc8ee5..aeb2d54 100644
+--- a/tools/python_api/test/test_connection.py
++++ b/tools/python_api/test/test_connection.py
+@@ -46,6 +46,10 @@ def test_connection_interrupt(conn_db_readwrite: ConnDB) -> None:
+     execute_thread = threading.Thread(target=run_long_query, args=(conn,))
+     execute_thread.start()
+     time.sleep(5)
+-    conn.interrupt()
+-    execute_thread.join(timeout=100)
++    # Compiling this query can outlast the sleep on a slow machine, and the interrupt flag is
++    # cleared when execution starts, so an interrupt sent during compilation is lost; repeat it.
++    deadline = time.monotonic() + 100
++    while execute_thread.is_alive() and time.monotonic() < deadline:
++        conn.interrupt()
++        execute_thread.join(timeout=1)
+     assert not execute_thread.is_alive()
diff --git a/patches/ladybug/0.20.3/0003-extension-report-riscv64-as-its-own-platform.patch b/patches/ladybug/0.20.3/0003-extension-report-riscv64-as-its-own-platform.patch
new file mode 100644
index 00000000000..ba6c25260cc
--- /dev/null
+++ b/patches/ladybug/0.20.3/0003-extension-report-riscv64-as-its-own-platform.patch
@@ -0,0 +1,33 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Sun, 27 Sep 2026 00:00:00 +0000
+Subject: [PATCH] extension: report riscv64 as its own platform
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+getArch() starts from "amd64" and only overrides it for x86 and arm64,
+so on riscv64 getPlatform() returns "linux_amd64". INSTALL then
+downloads the x86-64 build of an extension from
+extension.ladybugdb.com into ~/.lbdb/extension/<ver>/linux_amd64/,
+and LOAD fails with "cannot open shared object file: No such file or
+directory", which is how glibc's dlopen reports an ELF for another
+machine. Seen in test_json.py's INSTALL json; LOAD json on the riscv64
+runners. Still present on main.
+
+Return "riscv64" there, so INSTALL looks for linux_riscv64 builds
+(upstream publishes none yet) and the extension cache is keyed by the
+right platform.
+---
+diff --git a/src/extension/extension.cpp b/src/extension/extension.cpp
+index e87004f..e9e2891 100644
+--- a/src/extension/extension.cpp
++++ b/src/extension/extension.cpp
+@@ -144,6 +144,8 @@ std::string getArch() {
+     arch = "x86";
+ #elif defined(__aarch64__) || defined(__ARM_ARCH_ISA_A64)
+     arch = "arm64";
++#elif defined(__riscv) && __riscv_xlen == 64
++    arch = "riscv64";
+ #endif
+     return arch;
+ }
diff --git a/patches/ladybug/0.20.4/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch b/patches/ladybug/0.20.4/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
new file mode 100644
index 00000000000..9c58b6d45f1
--- /dev/null
+++ b/patches/ladybug/0.20.4/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
@@ -0,0 +1,48 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Fri, 25 Sep 2026 00:00:00 +0000
+Subject: [PATCH] storage: shrink the VMRegion reservation until it fits
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+Every Database reserves its buffer-manager region with one mmap of
+max_db_size bytes, and max_db_size defaults to 1 << 43 (8TB). riscv64
+Sv39 gives a process 256GB of user address space (the T-Head C910/C920
+cores the riscv64 runners use only implement Sv39), so the reservation
+fails with ENOMEM and every Database() created with the default
+settings throws "Mmap for size 8796093022208 failed." The same happens
+under a 39-bit VA arm64 kernel, or on x86-64 under
+`ulimit -v 268435456`. Still present in v0.20.4.
+
+On ENOMEM, halve the reservation until it fits. Where the full region
+fits nothing changes; elsewhere the database is capped at the largest
+power-of-two region the address space can hold, the limit
+max_db_size already expresses.
+---
+diff --git a/src/storage/buffer_manager/vm_region.cpp b/src/storage/buffer_manager/vm_region.cpp
+index 429bc61..d102eef 100644
+--- a/src/storage/buffer_manager/vm_region.cpp
++++ b/src/storage/buffer_manager/vm_region.cpp
+@@ -13,6 +13,8 @@
+ #else
+ #include <sys/mman.h>
+ #include <unistd.h>
++
++#include <cerrno>
+ #endif
+ 
+ #include "common/assert.h"
+@@ -61,6 +63,13 @@ VMRegion::VMRegion(PageSizeClass pageSizeClass, uint64_t maxRegionSize) : numFra
+     // backed by any file, and its content are initialized to zero.
+     region = static_cast<uint8_t*>(mmap(NULL, getMaxRegionSize(), PROT_READ | PROT_WRITE,
+         MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1 /* fd */, 0 /* offset */));
++    // The default 8TB region does not fit in a smaller user address space (256GB under riscv64
++    // Sv39, 512GB under a 39-bit VA arm64 kernel), so halve the reservation until it does.
++    while (region == MAP_FAILED && errno == ENOMEM && maxNumFrameGroups > 1) {
++        maxNumFrameGroups /= 2;
++        region = static_cast<uint8_t*>(mmap(NULL, getMaxRegionSize(), PROT_READ | PROT_WRITE,
++            MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1 /* fd */, 0 /* offset */));
++    }
+     if (region == MAP_FAILED) {
+         throw BufferManagerException(
+             "Mmap for size " + std::to_string(getMaxRegionSize()) + " failed.");
diff --git a/patches/ladybug/0.20.4/0002-test-repeat-the-interrupt-until-the-query-stops.patch b/patches/ladybug/0.20.4/0002-test-repeat-the-interrupt-until-the-query-stops.patch
new file mode 100644
index 00000000000..fda78c4815a
--- /dev/null
+++ b/patches/ladybug/0.20.4/0002-test-repeat-the-interrupt-until-the-query-stops.patch
@@ -0,0 +1,41 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Sat, 27 Sep 2026 00:00:00 +0000
+Subject: [PATCH] test: repeat the interrupt until the query stops
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+test_connection_interrupt starts a long query on a thread, sleeps 5s,
+calls conn.interrupt() once and expects the thread to end within 100s.
+Binding folds each RANGE(1, 1000000) into a million-element list
+literal, and ClientContext::executeNoLock() calls resetActiveQuery(),
+which clears the interrupted flag, only once compilation is done. On
+the riscv64 runners compiling the query takes longer than 5s, so the
+interrupt lands during compilation, is wiped, and the query keeps
+running. The fixture teardown's close() then waits on it for about 4
+hours, and the query thread segfaults freeing its FactorizedTable
+after the database is gone. The same loss reproduces on x86-64 with
+upstream's 0.19.1 wheel when the sleep is shorter than the compile.
+Still present on ladybug-python main.
+
+Re-issue the interrupt every second until the thread ends, within the
+same 100s budget. On a fast machine the first interrupt still sticks
+and the test behaves as before.
+---
+diff --git a/tools/python_api/test/test_connection.py b/tools/python_api/test/test_connection.py
+index dcc8ee5..aeb2d54 100644
+--- a/tools/python_api/test/test_connection.py
++++ b/tools/python_api/test/test_connection.py
+@@ -46,6 +46,10 @@ def test_connection_interrupt(conn_db_readwrite: ConnDB) -> None:
+     execute_thread = threading.Thread(target=run_long_query, args=(conn,))
+     execute_thread.start()
+     time.sleep(5)
+-    conn.interrupt()
+-    execute_thread.join(timeout=100)
++    # Compiling this query can outlast the sleep on a slow machine, and the interrupt flag is
++    # cleared when execution starts, so an interrupt sent during compilation is lost; repeat it.
++    deadline = time.monotonic() + 100
++    while execute_thread.is_alive() and time.monotonic() < deadline:
++        conn.interrupt()
++        execute_thread.join(timeout=1)
+     assert not execute_thread.is_alive()
diff --git a/patches/ladybug/0.20.4/0003-extension-report-riscv64-as-its-own-platform.patch b/patches/ladybug/0.20.4/0003-extension-report-riscv64-as-its-own-platform.patch
new file mode 100644
index 00000000000..ba6c25260cc
--- /dev/null
+++ b/patches/ladybug/0.20.4/0003-extension-report-riscv64-as-its-own-platform.patch
@@ -0,0 +1,33 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Sun, 27 Sep 2026 00:00:00 +0000
+Subject: [PATCH] extension: report riscv64 as its own platform
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+getArch() starts from "amd64" and only overrides it for x86 and arm64,
+so on riscv64 getPlatform() returns "linux_amd64". INSTALL then
+downloads the x86-64 build of an extension from
+extension.ladybugdb.com into ~/.lbdb/extension/<ver>/linux_amd64/,
+and LOAD fails with "cannot open shared object file: No such file or
+directory", which is how glibc's dlopen reports an ELF for another
+machine. Seen in test_json.py's INSTALL json; LOAD json on the riscv64
+runners. Still present on main.
+
+Return "riscv64" there, so INSTALL looks for linux_riscv64 builds
+(upstream publishes none yet) and the extension cache is keyed by the
+right platform.
+---
+diff --git a/src/extension/extension.cpp b/src/extension/extension.cpp
+index e87004f..e9e2891 100644
+--- a/src/extension/extension.cpp
++++ b/src/extension/extension.cpp
+@@ -144,6 +144,8 @@ std::string getArch() {
+     arch = "x86";
+ #elif defined(__aarch64__) || defined(__ARM_ARCH_ISA_A64)
+     arch = "arm64";
++#elif defined(__riscv) && __riscv_xlen == 64
++    arch = "riscv64";
+ #endif
+     return arch;
+ }
diff --git a/patches/ladybug/0.21.0/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch b/patches/ladybug/0.21.0/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
new file mode 100644
index 00000000000..9c58b6d45f1
--- /dev/null
+++ b/patches/ladybug/0.21.0/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
@@ -0,0 +1,48 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Fri, 25 Sep 2026 00:00:00 +0000
+Subject: [PATCH] storage: shrink the VMRegion reservation until it fits
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+Every Database reserves its buffer-manager region with one mmap of
+max_db_size bytes, and max_db_size defaults to 1 << 43 (8TB). riscv64
+Sv39 gives a process 256GB of user address space (the T-Head C910/C920
+cores the riscv64 runners use only implement Sv39), so the reservation
+fails with ENOMEM and every Database() created with the default
+settings throws "Mmap for size 8796093022208 failed." The same happens
+under a 39-bit VA arm64 kernel, or on x86-64 under
+`ulimit -v 268435456`. Still present in v0.20.4.
+
+On ENOMEM, halve the reservation until it fits. Where the full region
+fits nothing changes; elsewhere the database is capped at the largest
+power-of-two region the address space can hold, the limit
+max_db_size already expresses.
+---
+diff --git a/src/storage/buffer_manager/vm_region.cpp b/src/storage/buffer_manager/vm_region.cpp
+index 429bc61..d102eef 100644
+--- a/src/storage/buffer_manager/vm_region.cpp
++++ b/src/storage/buffer_manager/vm_region.cpp
+@@ -13,6 +13,8 @@
+ #else
+ #include <sys/mman.h>
+ #include <unistd.h>
++
++#include <cerrno>
+ #endif
+ 
+ #include "common/assert.h"
+@@ -61,6 +63,13 @@ VMRegion::VMRegion(PageSizeClass pageSizeClass, uint64_t maxRegionSize) : numFra
+     // backed by any file, and its content are initialized to zero.
+     region = static_cast<uint8_t*>(mmap(NULL, getMaxRegionSize(), PROT_READ | PROT_WRITE,
+         MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1 /* fd */, 0 /* offset */));
++    // The default 8TB region does not fit in a smaller user address space (256GB under riscv64
++    // Sv39, 512GB under a 39-bit VA arm64 kernel), so halve the reservation until it does.
++    while (region == MAP_FAILED && errno == ENOMEM && maxNumFrameGroups > 1) {
++        maxNumFrameGroups /= 2;
++        region = static_cast<uint8_t*>(mmap(NULL, getMaxRegionSize(), PROT_READ | PROT_WRITE,
++            MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1 /* fd */, 0 /* offset */));
++    }
+     if (region == MAP_FAILED) {
+         throw BufferManagerException(
+             "Mmap for size " + std::to_string(getMaxRegionSize()) + " failed.");
diff --git a/patches/ladybug/0.21.0/0002-test-repeat-the-interrupt-until-the-query-stops.patch b/patches/ladybug/0.21.0/0002-test-repeat-the-interrupt-until-the-query-stops.patch
new file mode 100644
index 00000000000..fda78c4815a
--- /dev/null
+++ b/patches/ladybug/0.21.0/0002-test-repeat-the-interrupt-until-the-query-stops.patch
@@ -0,0 +1,41 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Sat, 27 Sep 2026 00:00:00 +0000
+Subject: [PATCH] test: repeat the interrupt until the query stops
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+test_connection_interrupt starts a long query on a thread, sleeps 5s,
+calls conn.interrupt() once and expects the thread to end within 100s.
+Binding folds each RANGE(1, 1000000) into a million-element list
+literal, and ClientContext::executeNoLock() calls resetActiveQuery(),
+which clears the interrupted flag, only once compilation is done. On
+the riscv64 runners compiling the query takes longer than 5s, so the
+interrupt lands during compilation, is wiped, and the query keeps
+running. The fixture teardown's close() then waits on it for about 4
+hours, and the query thread segfaults freeing its FactorizedTable
+after the database is gone. The same loss reproduces on x86-64 with
+upstream's 0.19.1 wheel when the sleep is shorter than the compile.
+Still present on ladybug-python main.
+
+Re-issue the interrupt every second until the thread ends, within the
+same 100s budget. On a fast machine the first interrupt still sticks
+and the test behaves as before.
+---
+diff --git a/tools/python_api/test/test_connection.py b/tools/python_api/test/test_connection.py
+index dcc8ee5..aeb2d54 100644
+--- a/tools/python_api/test/test_connection.py
++++ b/tools/python_api/test/test_connection.py
+@@ -46,6 +46,10 @@ def test_connection_interrupt(conn_db_readwrite: ConnDB) -> None:
+     execute_thread = threading.Thread(target=run_long_query, args=(conn,))
+     execute_thread.start()
+     time.sleep(5)
+-    conn.interrupt()
+-    execute_thread.join(timeout=100)
++    # Compiling this query can outlast the sleep on a slow machine, and the interrupt flag is
++    # cleared when execution starts, so an interrupt sent during compilation is lost; repeat it.
++    deadline = time.monotonic() + 100
++    while execute_thread.is_alive() and time.monotonic() < deadline:
++        conn.interrupt()
++        execute_thread.join(timeout=1)
+     assert not execute_thread.is_alive()
diff --git a/patches/ladybug/0.21.0/0003-extension-report-riscv64-as-its-own-platform.patch b/patches/ladybug/0.21.0/0003-extension-report-riscv64-as-its-own-platform.patch
new file mode 100644
index 00000000000..ba6c25260cc
--- /dev/null
+++ b/patches/ladybug/0.21.0/0003-extension-report-riscv64-as-its-own-platform.patch
@@ -0,0 +1,33 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Sun, 27 Sep 2026 00:00:00 +0000
+Subject: [PATCH] extension: report riscv64 as its own platform
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+getArch() starts from "amd64" and only overrides it for x86 and arm64,
+so on riscv64 getPlatform() returns "linux_amd64". INSTALL then
+downloads the x86-64 build of an extension from
+extension.ladybugdb.com into ~/.lbdb/extension/<ver>/linux_amd64/,
+and LOAD fails with "cannot open shared object file: No such file or
+directory", which is how glibc's dlopen reports an ELF for another
+machine. Seen in test_json.py's INSTALL json; LOAD json on the riscv64
+runners. Still present on main.
+
+Return "riscv64" there, so INSTALL looks for linux_riscv64 builds
+(upstream publishes none yet) and the extension cache is keyed by the
+right platform.
+---
+diff --git a/src/extension/extension.cpp b/src/extension/extension.cpp
+index e87004f..e9e2891 100644
+--- a/src/extension/extension.cpp
++++ b/src/extension/extension.cpp
+@@ -144,6 +144,8 @@ std::string getArch() {
+     arch = "x86";
+ #elif defined(__aarch64__) || defined(__ARM_ARCH_ISA_A64)
+     arch = "arm64";
++#elif defined(__riscv) && __riscv_xlen == 64
++    arch = "riscv64";
+ #endif
+     return arch;
+ }
diff --git a/patches/ladybug/0.21.1/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch b/patches/ladybug/0.21.1/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
new file mode 100644
index 00000000000..9c58b6d45f1
--- /dev/null
+++ b/patches/ladybug/0.21.1/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
@@ -0,0 +1,48 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Fri, 25 Sep 2026 00:00:00 +0000
+Subject: [PATCH] storage: shrink the VMRegion reservation until it fits
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+Every Database reserves its buffer-manager region with one mmap of
+max_db_size bytes, and max_db_size defaults to 1 << 43 (8TB). riscv64
+Sv39 gives a process 256GB of user address space (the T-Head C910/C920
+cores the riscv64 runners use only implement Sv39), so the reservation
+fails with ENOMEM and every Database() created with the default
+settings throws "Mmap for size 8796093022208 failed." The same happens
+under a 39-bit VA arm64 kernel, or on x86-64 under
+`ulimit -v 268435456`. Still present in v0.20.4.
+
+On ENOMEM, halve the reservation until it fits. Where the full region
+fits nothing changes; elsewhere the database is capped at the largest
+power-of-two region the address space can hold, the limit
+max_db_size already expresses.
+---
+diff --git a/src/storage/buffer_manager/vm_region.cpp b/src/storage/buffer_manager/vm_region.cpp
+index 429bc61..d102eef 100644
+--- a/src/storage/buffer_manager/vm_region.cpp
++++ b/src/storage/buffer_manager/vm_region.cpp
+@@ -13,6 +13,8 @@
+ #else
+ #include <sys/mman.h>
+ #include <unistd.h>
++
++#include <cerrno>
+ #endif
+ 
+ #include "common/assert.h"
+@@ -61,6 +63,13 @@ VMRegion::VMRegion(PageSizeClass pageSizeClass, uint64_t maxRegionSize) : numFra
+     // backed by any file, and its content are initialized to zero.
+     region = static_cast<uint8_t*>(mmap(NULL, getMaxRegionSize(), PROT_READ | PROT_WRITE,
+         MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1 /* fd */, 0 /* offset */));
++    // The default 8TB region does not fit in a smaller user address space (256GB under riscv64
++    // Sv39, 512GB under a 39-bit VA arm64 kernel), so halve the reservation until it does.
++    while (region == MAP_FAILED && errno == ENOMEM && maxNumFrameGroups > 1) {
++        maxNumFrameGroups /= 2;
++        region = static_cast<uint8_t*>(mmap(NULL, getMaxRegionSize(), PROT_READ | PROT_WRITE,
++            MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1 /* fd */, 0 /* offset */));
++    }
+     if (region == MAP_FAILED) {
+         throw BufferManagerException(
+             "Mmap for size " + std::to_string(getMaxRegionSize()) + " failed.");
diff --git a/patches/ladybug/0.21.1/0002-test-repeat-the-interrupt-until-the-query-stops.patch b/patches/ladybug/0.21.1/0002-test-repeat-the-interrupt-until-the-query-stops.patch
new file mode 100644
index 00000000000..fda78c4815a
--- /dev/null
+++ b/patches/ladybug/0.21.1/0002-test-repeat-the-interrupt-until-the-query-stops.patch
@@ -0,0 +1,41 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Sat, 27 Sep 2026 00:00:00 +0000
+Subject: [PATCH] test: repeat the interrupt until the query stops
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+test_connection_interrupt starts a long query on a thread, sleeps 5s,
+calls conn.interrupt() once and expects the thread to end within 100s.
+Binding folds each RANGE(1, 1000000) into a million-element list
+literal, and ClientContext::executeNoLock() calls resetActiveQuery(),
+which clears the interrupted flag, only once compilation is done. On
+the riscv64 runners compiling the query takes longer than 5s, so the
+interrupt lands during compilation, is wiped, and the query keeps
+running. The fixture teardown's close() then waits on it for about 4
+hours, and the query thread segfaults freeing its FactorizedTable
+after the database is gone. The same loss reproduces on x86-64 with
+upstream's 0.19.1 wheel when the sleep is shorter than the compile.
+Still present on ladybug-python main.
+
+Re-issue the interrupt every second until the thread ends, within the
+same 100s budget. On a fast machine the first interrupt still sticks
+and the test behaves as before.
+---
+diff --git a/tools/python_api/test/test_connection.py b/tools/python_api/test/test_connection.py
+index dcc8ee5..aeb2d54 100644
+--- a/tools/python_api/test/test_connection.py
++++ b/tools/python_api/test/test_connection.py
+@@ -46,6 +46,10 @@ def test_connection_interrupt(conn_db_readwrite: ConnDB) -> None:
+     execute_thread = threading.Thread(target=run_long_query, args=(conn,))
+     execute_thread.start()
+     time.sleep(5)
+-    conn.interrupt()
+-    execute_thread.join(timeout=100)
++    # Compiling this query can outlast the sleep on a slow machine, and the interrupt flag is
++    # cleared when execution starts, so an interrupt sent during compilation is lost; repeat it.
++    deadline = time.monotonic() + 100
++    while execute_thread.is_alive() and time.monotonic() < deadline:
++        conn.interrupt()
++        execute_thread.join(timeout=1)
+     assert not execute_thread.is_alive()
diff --git a/patches/ladybug/0.21.1/0003-extension-report-riscv64-as-its-own-platform.patch b/patches/ladybug/0.21.1/0003-extension-report-riscv64-as-its-own-platform.patch
new file mode 100644
index 00000000000..ba6c25260cc
--- /dev/null
+++ b/patches/ladybug/0.21.1/0003-extension-report-riscv64-as-its-own-platform.patch
@@ -0,0 +1,33 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Sun, 27 Sep 2026 00:00:00 +0000
+Subject: [PATCH] extension: report riscv64 as its own platform
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+getArch() starts from "amd64" and only overrides it for x86 and arm64,
+so on riscv64 getPlatform() returns "linux_amd64". INSTALL then
+downloads the x86-64 build of an extension from
+extension.ladybugdb.com into ~/.lbdb/extension/<ver>/linux_amd64/,
+and LOAD fails with "cannot open shared object file: No such file or
+directory", which is how glibc's dlopen reports an ELF for another
+machine. Seen in test_json.py's INSTALL json; LOAD json on the riscv64
+runners. Still present on main.
+
+Return "riscv64" there, so INSTALL looks for linux_riscv64 builds
+(upstream publishes none yet) and the extension cache is keyed by the
+right platform.
+---
+diff --git a/src/extension/extension.cpp b/src/extension/extension.cpp
+index e87004f..e9e2891 100644
+--- a/src/extension/extension.cpp
++++ b/src/extension/extension.cpp
+@@ -144,6 +144,8 @@ std::string getArch() {
+     arch = "x86";
+ #elif defined(__aarch64__) || defined(__ARM_ARCH_ISA_A64)
+     arch = "arm64";
++#elif defined(__riscv) && __riscv_xlen == 64
++    arch = "riscv64";
+ #endif
+     return arch;
+ }
diff --git a/patches/ladybug/0.21.2/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch b/patches/ladybug/0.21.2/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
new file mode 100644
index 00000000000..9c58b6d45f1
--- /dev/null
+++ b/patches/ladybug/0.21.2/0001-storage-shrink-the-VMRegion-reservation-until-it-fits.patch
@@ -0,0 +1,48 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Fri, 25 Sep 2026 00:00:00 +0000
+Subject: [PATCH] storage: shrink the VMRegion reservation until it fits
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+Every Database reserves its buffer-manager region with one mmap of
+max_db_size bytes, and max_db_size defaults to 1 << 43 (8TB). riscv64
+Sv39 gives a process 256GB of user address space (the T-Head C910/C920
+cores the riscv64 runners use only implement Sv39), so the reservation
+fails with ENOMEM and every Database() created with the default
+settings throws "Mmap for size 8796093022208 failed." The same happens
+under a 39-bit VA arm64 kernel, or on x86-64 under
+`ulimit -v 268435456`. Still present in v0.20.4.
+
+On ENOMEM, halve the reservation until it fits. Where the full region
+fits nothing changes; elsewhere the database is capped at the largest
+power-of-two region the address space can hold, the limit
+max_db_size already expresses.
+---
+diff --git a/src/storage/buffer_manager/vm_region.cpp b/src/storage/buffer_manager/vm_region.cpp
+index 429bc61..d102eef 100644
+--- a/src/storage/buffer_manager/vm_region.cpp
++++ b/src/storage/buffer_manager/vm_region.cpp
+@@ -13,6 +13,8 @@
+ #else
+ #include <sys/mman.h>
+ #include <unistd.h>
++
++#include <cerrno>
+ #endif
+ 
+ #include "common/assert.h"
+@@ -61,6 +63,13 @@ VMRegion::VMRegion(PageSizeClass pageSizeClass, uint64_t maxRegionSize) : numFra
+     // backed by any file, and its content are initialized to zero.
+     region = static_cast<uint8_t*>(mmap(NULL, getMaxRegionSize(), PROT_READ | PROT_WRITE,
+         MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1 /* fd */, 0 /* offset */));
++    // The default 8TB region does not fit in a smaller user address space (256GB under riscv64
++    // Sv39, 512GB under a 39-bit VA arm64 kernel), so halve the reservation until it does.
++    while (region == MAP_FAILED && errno == ENOMEM && maxNumFrameGroups > 1) {
++        maxNumFrameGroups /= 2;
++        region = static_cast<uint8_t*>(mmap(NULL, getMaxRegionSize(), PROT_READ | PROT_WRITE,
++            MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1 /* fd */, 0 /* offset */));
++    }
+     if (region == MAP_FAILED) {
+         throw BufferManagerException(
+             "Mmap for size " + std::to_string(getMaxRegionSize()) + " failed.");
diff --git a/patches/ladybug/0.21.2/0002-test-repeat-the-interrupt-until-the-query-stops.patch b/patches/ladybug/0.21.2/0002-test-repeat-the-interrupt-until-the-query-stops.patch
new file mode 100644
index 00000000000..fda78c4815a
--- /dev/null
+++ b/patches/ladybug/0.21.2/0002-test-repeat-the-interrupt-until-the-query-stops.patch
@@ -0,0 +1,41 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Sat, 27 Sep 2026 00:00:00 +0000
+Subject: [PATCH] test: repeat the interrupt until the query stops
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+test_connection_interrupt starts a long query on a thread, sleeps 5s,
+calls conn.interrupt() once and expects the thread to end within 100s.
+Binding folds each RANGE(1, 1000000) into a million-element list
+literal, and ClientContext::executeNoLock() calls resetActiveQuery(),
+which clears the interrupted flag, only once compilation is done. On
+the riscv64 runners compiling the query takes longer than 5s, so the
+interrupt lands during compilation, is wiped, and the query keeps
+running. The fixture teardown's close() then waits on it for about 4
+hours, and the query thread segfaults freeing its FactorizedTable
+after the database is gone. The same loss reproduces on x86-64 with
+upstream's 0.19.1 wheel when the sleep is shorter than the compile.
+Still present on ladybug-python main.
+
+Re-issue the interrupt every second until the thread ends, within the
+same 100s budget. On a fast machine the first interrupt still sticks
+and the test behaves as before.
+---
+diff --git a/tools/python_api/test/test_connection.py b/tools/python_api/test/test_connection.py
+index dcc8ee5..aeb2d54 100644
+--- a/tools/python_api/test/test_connection.py
++++ b/tools/python_api/test/test_connection.py
+@@ -46,6 +46,10 @@ def test_connection_interrupt(conn_db_readwrite: ConnDB) -> None:
+     execute_thread = threading.Thread(target=run_long_query, args=(conn,))
+     execute_thread.start()
+     time.sleep(5)
+-    conn.interrupt()
+-    execute_thread.join(timeout=100)
++    # Compiling this query can outlast the sleep on a slow machine, and the interrupt flag is
++    # cleared when execution starts, so an interrupt sent during compilation is lost; repeat it.
++    deadline = time.monotonic() + 100
++    while execute_thread.is_alive() and time.monotonic() < deadline:
++        conn.interrupt()
++        execute_thread.join(timeout=1)
+     assert not execute_thread.is_alive()
diff --git a/patches/ladybug/0.21.2/0003-extension-report-riscv64-as-its-own-platform.patch b/patches/ladybug/0.21.2/0003-extension-report-riscv64-as-its-own-platform.patch
new file mode 100644
index 00000000000..ba6c25260cc
--- /dev/null
+++ b/patches/ladybug/0.21.2/0003-extension-report-riscv64-as-its-own-platform.patch
@@ -0,0 +1,33 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ludovic Henry <git@ludovic.dev>
+Date: Sun, 27 Sep 2026 00:00:00 +0000
+Subject: [PATCH] extension: report riscv64 as its own platform
+
+Upstream-Status: To upstream [not yet submitted; python-wheels does not open issues/PRs on third-party repos]
+
+getArch() starts from "amd64" and only overrides it for x86 and arm64,
+so on riscv64 getPlatform() returns "linux_amd64". INSTALL then
+downloads the x86-64 build of an extension from
+extension.ladybugdb.com into ~/.lbdb/extension/<ver>/linux_amd64/,
+and LOAD fails with "cannot open shared object file: No such file or
+directory", which is how glibc's dlopen reports an ELF for another
+machine. Seen in test_json.py's INSTALL json; LOAD json on the riscv64
+runners. Still present on main.
+
+Return "riscv64" there, so INSTALL looks for linux_riscv64 builds
+(upstream publishes none yet) and the extension cache is keyed by the
+right platform.
+---
+diff --git a/src/extension/extension.cpp b/src/extension/extension.cpp
+index e87004f..e9e2891 100644
+--- a/src/extension/extension.cpp
++++ b/src/extension/extension.cpp
+@@ -144,6 +144,8 @@ std::string getArch() {
+     arch = "x86";
+ #elif defined(__aarch64__) || defined(__ARM_ARCH_ISA_A64)
+     arch = "arm64";
++#elif defined(__riscv) && __riscv_xlen == 64
++    arch = "riscv64";
+ #endif
+     return arch;
+ }

From 696f28578efe48b87c485e7503027d7ea4b92554 Mon Sep 17 00:00:00 2001
From: Ludovic Henry <git@ludovic.dev>
Date: Fri, 2 Oct 2026 21:46:29 +0000
Subject: [PATCH 3/3] ladybug: deselect the multi-writer MVCC stress test

test_mvcc_bank.py::test_multi_writer_no_anomalies aborted once, on the
0.20.3 cp314t leg. glibc's assertion fired in pthread_mutex_lock under
TaskScheduler::pushTaskIntoQueue. taskSchedulerMtx is a plain
std::mutex, and every access to it goes through that lock, so a mutex
whose owner field is already set means something else overwrote its
memory. This is not a memory-ordering bug in the scheduler, and none of
this branch's patches touch that code: the VMRegion fallback never runs
with the test's 1 GiB max_db_size.

Free threading is not the cause either. PyConnection::query releases
the GIL around Connection::query on every interpreter, and _lbug's
PYBIND11_MODULE declares no Py_mod_gil, so cp314t turns the GIL back
on at import. All four legs run the same concurrent C++. The same
upstream test file passed on the 0.20.2, 0.20.4, 0.21.0 and 0.21.1
cp314t legs, where 0.20.4 has the same python_api commit as 0.20.3,
and on every GIL leg. 32 runs of upstream's x86_64 cp314 0.20.3 wheel
also passed. That fits a rare race in enable_multi_writes. Upstream's
CI tests only CPython 3.12 on x86_64 and ships no cp314t wheel.
---
 .github/workflows/build-ladybug.yml | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/.github/workflows/build-ladybug.yml b/.github/workflows/build-ladybug.yml
index 895f36dedaa..1e57c15edb1 100644
--- a/.github/workflows/build-ladybug.yml
+++ b/.github/workflows/build-ladybug.yml
@@ -225,9 +225,19 @@ jobs:
             ${{ matrix.python != 'cp314t' && 'pandas~=2.2 polars~=1.30' || 'pytz' }}
           # test_fsm.py fails the same way with upstream's own x86_64 0.19.1 wheel. The deselected
           # test_json.py tests INSTALL the json extension from upstream's server, which has no riscv64 build.
+          # test_multi_writer_no_anomalies (4 writers + 2 readers on one Database with
+          # enable_multi_writes, 15s) aborted once on 0.20.3 cp314t: glibc's assertion in
+          # pthread_mutex_lock on TaskScheduler::taskSchedulerMtx, a plain std::mutex, so its memory
+          # was clobbered by something else rather than mis-ordered (gotcha 285). It is not
+          # free-threading: Connection::query drops the GIL on every interpreter and _lbug declares
+          # no Py_mod_gil, so cp314t runs with the GIL back on (gotcha 127). The same test tree
+          # passed on 0.20.4 cp314t and every other leg, and 32 runs of upstream's x86_64 wheel
+          # passed, as expected for a rare race. Upstream tests only CPython 3.12 on x86_64 and keeps
+          # fixing races like this one (#766, #840, #934), so we deselect the test rather than debug it.
           CIBW_TEST_COMMAND: >-
             python -m pytest -vv tools/python_api/test
             --ignore=tools/python_api/test/test_fsm.py
+            --deselect=tools/python_api/test/test_mvcc_bank.py::test_multi_writer_no_anomalies
             --deselect=tools/python_api/test/test_json.py::test_to_json_string_param_roundtrip
             --deselect=tools/python_api/test/test_json.py::test_to_json_python_param_with_mixed_nested_list
             --deselect=tools/python_api/test/test_json.py::test_get_as_df_json_extract