Fix One, Miss Another: Leveraging Historical Bug Fixes to Uncover Residual Bugs in Database Systems

Fix One, Miss Another: Leveraging Historical Bug Fixes to Uncover Residual Bugs in Database Systems

arXiv:2611.07739v1 [cs.SE] 5 Nov 2026

YANKAI RONG, Renmin University of China, China ZHAOYANG ZHANG, Renmin University of China, China SHUANG LIU, Renmin University of China, China WEI LU, Renmin University of China, China XIAOYONG DU, Renmin University of China, China Database management systems (DBMSs) implement SQL constructs through grammar-driven dispatch handlers. Although handlers for syntactic siblings implement different SQL constructs, they often share a common implementation pattern, including argument extraction, type checking, and permission validation. Consequently, a bug fix that hardens the handler exercised by a historical bug may leave the corresponding logic in sibling handlers vulnerable to the same semantic flaw. We refer to such defects as sibling bugs. Despite the structural similarity among sibling handlers, existing bug-finding techniques rarely exploit historical fixes to systematically uncover these related defects. We present Reaper, a novel approach for detecting sibling bugs guided by historical bug fixes. Reaper first analyzes a bug fix to infer a trigger profile, which characterizes the conditions under which the defect is exposed, and a validation profile, which captures the semantic evidence needed to distinguish buggy behavior from correct behavior. It then projects the trigger profile onto syntactic siblings through grammar-guided test mutation, generating tests that exercise corresponding semantic paths in sibling handlers. Finally, Reaper validates suspicious behaviors using the inferred validation profile through a staged validation process, reducing false positives caused by complex DBMS behavior. We evaluate Reaper on four widely used DBMSs—MariaDB, MySQL, OceanBase, and CockroachDB. Reaper uncovers 61 previously unknown bugs, of which 57 have been confirmed by developers and 13 have been fixed at the time of writing. These results demonstrate that historical bug fixes contain actionable semantic knowledge that can be systematically transferred across syntactic siblings to uncover otherwise overlooked defects.

1

Introduction

The Structured Query Language (SQL) is a declarative language whose behavior is specified in the ISO/IEC 9075 standard [6]. Each syntactic element/construct of the standard is defined through a format expressed as a BNF production, accompanied by the Syntax Rules, Access Rules, and General Rules that govern its processing. Modern DBMSs [3, 17, 19, 20] implement these specifications through a grammar-driven architecture: a recognized SQL construct is routed by a dispatcher to a dedicated handler responsible for its execution. This recurring architectural pattern is what we call the handler dispatch pattern [12, 21–24, 31]. The handler dispatch structure is directly mirrored by a grammar’s production rule: the lefthand-side non-terminal of a production rule corresponds to the dispatcher, and its right-hand-side alternatives correspond to the construct-specific handlers. Figure 1(b) illustrates this correspondence through the MariaDB sequence functions NEXTVAL and SETVAL. These two constructs originate from the same left-hand-side non-terminal in the BNF grammar and share similar semantics—both resolve a sequence object and then apply a form-specific effect. In the implementation, the virtual Authors’ Contact Information: Yankai Rong, yankairong@ruc.edu.cn, Renmin University of China, Beijing, China; Zhaoyang Zhang, zhaoyangzhang@ruc.edu.cn, Renmin University of China, Beijing, China; Shuang Liu, Shuang.Liu@ruc.edu.cn, Renmin University of China, Beijing, China; Wei Lu, lu-wei@ruc.edu.cn, Renmin University of China, Beijing, China; Xiaoyong Du, duyong@ruc.edu.cn, Renmin University of China, Beijing, China.

2

Yankai Rong, Zhaoyang Zhang, Shuang Liu, Wei Lu, and Xiaoyong Du

Historical bug

BUG-33985

SELECT (WITH x(x) AS (SELECT 1) SELECT * FROM x WHERE (NEXTVAL(x))); before: SIGSEGV

=> after: ER_NOT_SEQUENCE2

Commit nextval::val_int Add an is_pure_alias() guard to Item_func_nextval::val_int() , returning ER_NOT_SEQUENCE2 instead of crashing.

1 Item_func_nextval::val_int() 2 DBUG_ENTER("Item_func_nextval::val_int");

(a) Historical fix

same LHS

Grammar (BNF) Column_default_non_parenthesized_expr: | NEXTVAL_SYM (table_ident) | SETVAL_SYM (table_ident, ...) Mapped to implementation

Implementation (dispatch) Item* -> val_int() virtual dispatch

--sql/item_func.cc

3 + if (table_list->is_pure_alias()) 4 + my_error(ER_NOT_SEQUENCE2,...); 5 update_table(); 6 thd = table->in_use;

Grammar-driven dispatch

nextval_handler

setval_handler

Item_func_nextval::val_int()

Item_func_setval::val_int()

(b) Grammar-driven dispatch

Sibling bug

BUG-39063

SELECT (WITH x(x) AS (SELECT 1) SELECT * FROM x WHERE (SETVAL(x,1))); Observed: SIGSEGV

≠ Expected: ER_NOT_SEQUENCE2

Commit setval::val_int Add is_pure_alias() guards to Item_func_setval::val_int(), returning ER_NOT_SEQUENCE2 instead of crashing.

--sql/item_func.cc 1 Item_func_setval::val_int() 2 DBUG_ENTER("Item_func_setval::val_int"); 3 + if (table_list->is_pure_alias())

4 + my_error(ER_NOT_SEQUENCE2,...); missing 5 update_table(); 6 thd = table->in_use;

(c) Confirmed sibling bug detected by Reaper

Fig. 1. Reaper Reveals an Unpropagated Fix in MariaDB.

function Item::val_int() serves as the dispatcher; the functions Item_func_nextval::val_int() and Item_func_setval::val_int() are the two sibling handlers responsible for NEXTVAL and SETVAL, respectively. Because sibling handlers share substantial common logic, they should evolve together: a bug uncovered in one handler is a strong signal that an analogous bug may exist in its siblings. In practice, however, developers fix a system based on a reported bug, which typically pinpoints only one handler. A fix applied to one handler therefore often leaves its siblings exposed to the same bug—a phenomenon we term a sibling bug. Figure 1(c) illustrates a sibling bug we identified in MariaDB, with respect to a historical bug shown in Figure 1(a). The constructs NEXTVAL and SETVAL originate from the same BNF production and both require their argument to resolve to a valid sequence object. The original bug, BUG #33985, was fixed by adding an is_pure_alias() guard only to the NEXTVAL handler; the accompanying regression test exercised only this construct. The sibling handler SETVAL was therefore left unfixed despite sharing an analogous implementation. Replacing NEXTVAL in the original bug triggering query with SETVAL therefore exercised analogous processing logic in the sibling handler and still triggered a server crash. We reported this sibling bug as BUG #39063, whose follow-up fix propagated the same guard to the SETVAL handler. However, systematically detecting sibling bugs remains non-trivial. Existing DBMS fuzzers explore syntactic spaces or execution paths [1, 2, 7, 11, 25, 27, 29, 31], but cannot exercise sibling handlers that may remain inconsistent after repairing the reported bugs. Bridging this gap requires overcoming three challenges: First, precisely recovering the bug-triggering and bug-validation conditions. Historical fix records often contain noisy and lengthy context, making it difficult to recover the bug-triggering conditions and the semantic evidence used to distinguish buggy behavior from correct behavior. The challenge is thus to distill a historical fix into a concise and actionable profile that captures both when the bug can be triggered and how its manifestation can be validated. Second, systematically exercising sibling handlers while preserving bug-triggering conditions. Blindly mutating a historical bug-triggering query does not systematically reach handlers implementing syntactic siblings of the original construct. More importantly, simply replacing the original construct with a sibling alternative may invalidate the conditions that expose the historical defect. Effective sibling testing therefore requires simultaneously satisfying two constraints: the generated query must be routed to the intended sibling handler, while preserving the relevant semantic conditions under which the historical bug is triggered. The challenge is to transform a historical bug-triggering query across syntactic siblings without losing its defecttriggering characteristics. Third, accurately validating sibling bugs without ground truth. Unlike conventional regression testing, a sibling query generally has no known expected result. It is also not necessarily semantically equivalent to the historical bug-triggering query, making direct result comparison

Fix One, Miss Another: Leveraging Historical Bug Fixes to Uncover Residual Bugs in Database Systems

3

inappropriate. Existing DBMS testing oracles based on equivalence-oriented metamorphic relations [22, 23, 26] or approximation relations [14] therefore cannot be directly applied to determine whether a suspicious sibling execution exhibits the same semantic defect. The challenge is to derive validation evidence from the historical fix and determine whether the sibling execution violates the semantic property associated with the original bug, without a predefined ground-truth result. To address these challenges, we present Reaper, a DBMS fuzzing framework that turns historical bug fixes into reusable probes for detecting sibling bugs. Reaper follows a profile–generate–validate pipeline consisting of three phases. Bug Profile Construction addresses the challenge of recovering actionable triggering and validation conditions from noisy fixes. We design a multi-agent system consisting of a Query Analyzer, a Patch Analyzer and an Orchestrator. The Query Analyzer identifies the bug-triggering construct and historical failure pattern, while the Patch Analyzer infers the correctness requirement from the fix. The Orchestrator reconciles these complementary findings into a Bug Profile containing trigger conditions and validation evidence. Sibling Test Generation addresses the challenge of reaching sibling handlers while preserving bug-triggering conditions. Reaper identifies sibling constructs from the SQL grammar and transforms historical bug-triggering queries to exercise those sibling handlers. A Concretizer then satisfies sibling-specific semantic constraints while preserving the relevant trigger conditions in the Bug Profile. Sibling Bug Validation addresses the challenge of validating sibling bugs without ground truth. Reaper validates sibling-bug candidates through a three-stage checking process: failure-pattern matching, criterion applicability checking, and fix-derived oracle checking. These stages reuse semantic evidence from the historical fix to determine whether sibling executions violate the corresponding correctness requirement. We evaluated Reaper on four widely used production DBMSs—MariaDB, MySQL, OceanBase, and CockroachDB. It uncovered 61 previously unknown bugs, including 50 logic bugs and 11 crash/fatal-error bugs; 57 have been confirmed and 13 have been fixed by upstream developers. In summary, this paper makes the following contributions:

• Insight. We identify sibling bugs, a class of residual DBMS bugs that arise when a localized fix corrects one implementation while a related sibling handler remains vulnerable to the same semantic flaw. We further observe that historical bug fixes encode actionable knowledge about both bug-triggering conditions and correctness requirements, which can serve as semantic anchors for systematically examining sibling implementations. • Methodology. We design and implement Reaper, a fix-guided DBMS fuzzing framework following a profile–generate–validate pipeline. Reaper constructs a Bug Profile from historical bug fix reports, identifies sibling constructs through a grammar relation graph, and generates sibling tests while preserving the historical triggering conditions. It then validates suspicious executions using fix-derived validation evidence, without requiring ground-truth results. • Real-world impact. We evaluate Reaper on MySQL, MariaDB, OceanBase, and CockroachDB. It uncovers 61 previously unknown bugs, including 50 logic bugs and 11 crash or fatal-error bugs. Among them, 57 have been confirmed and 13 have been fixed by upstream developers. These results demonstrate that incomplete repair propagation remains a practical maintenance challenge in real-world DBMSs and that Reaper provides a way to systematically identify such residual bugs.

4

2 2.1

Yankai Rong, Zhaoyang Zhang, Shuang Liu, Wei Lu, and Xiaoyong Du

Preliminaries Grammar-Driven SQL Processing in DBMSs

Modern DBMSs typically process an SQL query through several stages, including parsing, semantic analysis, optimization, and execution. After receiving a query, the DBMS first parses the input according to its SQL grammar to determine its syntactic structure and creates an internal representation for each recognized SQL construct. Throughout this process, different SQL constructs may be routed to different processing paths according to handler-selection information encoded in their internal representations, e.g., construct types, expression classes, or function/operator identifiers. SQL grammars provide a structural bridge between SQL constructs and these processing paths. ISO/IEC 9075 specifies SQL syntactic elements using BNF-style productions, while practical DBMSs maintain dialect grammars to describe their supported SQL constructs [6]. A production rule associates a left-hand-side nonterminal with one or more right-hand-side alternatives, each defining a distinct syntactic form of that nonterminal. As shown in Figure 1(b), in MariaDB, the grammar alternative for the SQL construct NEXTVAL is recognized during parsing and mapped to an Item_func_nextval object in the internal representation. During evaluation, the object is dispatched through the Item::val_int() interface to its handler Item_func_nextval::val_int(), which implements the sequence operation. This example illustrates the correspondence between grammar alternatives and construct-specific processing paths, where sibling alternatives may lead to distinct handlers implementing related semantics. 2.2

Syntactic Siblings and Handler Dispatch

Definition 1 (Syntactic Sibling). We refer to SQL constructs derived from different alternatives of the same left-hand-side nonterminal as syntactic siblings. Although syntactic siblings denote different SQL constructs, their shared grammatical role often leads them to enter the same processing framework before diverging into construct-specific behavior. Figure 1(b) illustrates NEXTVAL and SETVAL as syntactic siblings in MariaDB. Their grammar alternatives, NEXTVAL_SYM ’(’ table_ident ’)’ and SETVAL_SYM ’(’ table_ident ’,’ ... ’)’, share the same left-hand-side nonterminal. Here, NEXTVAL_SYM and SETVAL_SYM are grammar tokens representing the SQL keywords NEXTVAL and SETVAL, respectively. At the implementation level, this grammar structure is reflected by the handler dispatch pattern. A handler is the implementation selected by a dispatch decision to process a particular SQL construct. It may be realized as a dedicated function or method, or as a distinct branch within a shared implementation. Definition 2 (Sibling Handler). Sibling handlers are handlers implementing syntactic siblings. As shown in Figure 1(b), NEXTVAL and SETVAL are represented by Item_func_nextval and Item_func_setval within the same expression-processing framework. They share common preparation and evaluation interfaces. During evaluation, calls through the shared virtual interface Item::val_int() are dispatched to Item_func_nextval::val_int() or Item_func_setval:: val_int(), selecting the handler of the corresponding construct. Sibling handlers may further reuse preparation logic and auxiliary routines for object resolution, argument processing, and validation, while retaining separate execution paths for construct-specific semantics. 2.3 Sibling Bugs In a typical DBMS development workflow, a reported bug is reproduced by a failing query and localized to an implicated processing path. Developers patch that path and add a regression test to check that the historical failure does not recur. The patch therefore determines which implementation path is updated, while the regression test determines which triggering instance

Fix One, Miss Another: Leveraging Historical Bug Fixes to Uncover Residual Bugs in Database Systems

1

Bug Profile Construction

Regression test

Query Analyzer

2

Sibling Test Generation

Sibling Mutation

Bug Profile

Grammar Skeleton

Trigger Profile Bug-triggering construct

Concretizer

Key statement

Orchestrator

Match failure pattern

Validation Profile

Execute tests

Check criterion applicability

Failure pattern

Patch

Sibling tests

Regression test

Description

Patch Analyzer

5

Fix-derived criterion

Check oracle violation

Fix-derived oracle 3

Sibling Bug Validation

Bug report

Fig. 2. Overview of Reaper.

is exercised after the fix. Because both are typically centered on the reported construct, neither necessarily covers the construct-specific paths associated with its syntactic siblings. This distinction matters when sibling handlers follow different execution paths but are subject to the same correctness requirement. A repair confined to the reported path may correct the historical violation without updating the corresponding logic in a sibling path. The original regression test can therefore pass while another grammar alternative still reaches an implementation that violates the same requirement. In the motivating example in Figure 1, the repaired NEXTVAL handler rejects an invalid sequence reference, whereas the sibling SETVAL handler still crashes on the same reference. Both handlers should reject such references, but the historical fix corrects only the NEXTVAL path. We formally define such residual bugs as follows: Definition 3 (Sibling Bug). Two bugs are sibling bugs if they occur in sibling handlers and share the same bug-triggering conditions. Figure 1 illustrates how a localized fix leaves a sibling bug unresolved in MariaDB. The historical query calls NEXTVAL(x), where x does not refer to a sequence object. Instead of rejecting this invalid reference, the handler attempts to access it as a sequence object and crashes. The historical fix adds a check to reject the reference before sequence-object access, and the accompanying regression test verifies the repaired NEXTVAL path. However, the sibling SETVAL handler lacks the corresponding check. Replacing NEXTVAL(x) with SETVAL(x,1) retains the invalid reference while directing execution to this sibling handler. Although both constructs require a valid sequence reference, the SETVAL path still attempts sequence-object access and crashes, as shown in Figure 1(c). 3

Approach

Figure 2 provides an overview of Reaper, which consists of three components—Bug Profile Construction, Sibling Test Generation, and Sibling Bug Validation. Given a historical fix, Reaper generates and executes sibling tests to uncover sibling bugs. During Bug Profile Construction, three collaborating LLM agents analyze the regression test, bug description, and patch, integrating query-side and repair-side evidence into a Bug Profile comprising a trigger profile and a validation profile (§3.1). Then, the trigger profile guides Sibling Test Generation to produce sibling test cases that preserve the bug-triggering conditions (§3.2). Sibling Bug Validation then applies the validation profile in three stages. A sibling bug is reported only when the execution matches the failure pattern, the fix-derived criterion applies to the selected sibling, and the corresponding oracle, adapted to the sibling test, is violated (§3.3).

6

Yankai Rong, Zhaoyang Zhang, Shuang Liu, Wei Lu, and Xiaoyong Du

Historical fix Q: Regression test CREATE TABLE t1 (a int, b bit(2)); 311 + INSERT INTO t1 VALUES (3,2),(2,3),(2,0),(3,2),(3,1); 312 + SELECT COUNT(DISTINCT b) FROM t1 GROUP BY a; 313 + DROP TABLE t1; 310 +

D: Bug description BUG#30324: Grouping queries with COUNT(DISTINCT bit column) return wrong results … caused by COUNT(DISTINCT ...) uses a Unique object that assumes BIT(N) occupies contiguous space in the temporarytable record buffer.Fix is to … instruct create_tmp_table() to create a temporary-table column of type BIGINT, not BIT(N).

Δ: Code patch bool Item_sum_count_distinct::setup(THD *thd) 2468+

Make create_tmp_table() convert BIT columns to BIGINT.

…

…

2478 +

if (item->type() == Item::FIELD_ITEM && ((Item_field*)item)->field->type() == FIELD_TYPE_BIT) item->marker=4;

2479+

2480+

𝐷 + 𝛥

𝑄+𝐷

Query Analyzer

Patch Analyzer

Instructions 𝑄 1. Identify 𝑛𝑓𝑎𝑢𝑙𝑡 : use the diagnostic clues in 𝐷 to distinguish the bug-triggering construct in 𝑄 from surrounding trigger conditions. 𝑄 2. Extract 𝑆𝑘𝑒𝑦 : identify the complete statement in 𝑄 that contains 𝑛𝑓𝑎𝑢𝑙𝑡 and its surrounding trigger conditions. 3. Infer 𝑃𝑓𝑎𝑖𝑙 : identify the incorrect behavior described by 𝑄 and 𝐷, and abstract it into the failure pattern without retaining the concrete values of the historical execution.

Instructions 𝛥 1. Identify 𝑛𝑓𝑎𝑢𝑙𝑡 : trace the repaired handler in 𝛥 to its corresponding SQL construct. 2. Infer 𝐶𝑓𝑖𝑥 : relate the bug description in 𝐷 to the code change in 𝛥, determine the behavior restored by the repair, express it as a specification of the expected SQL behavior. 3. Infer 𝑂𝑓𝑖𝑥 : identify the stated premises from 𝐷 and 𝛥, and formulate a checkable condition or relation for determining incorrect execution behavior.

Example output

Example output

𝑄

𝛥 𝑛𝑓𝑎𝑢𝑙𝑡 : COUNT 𝐶𝑓𝑖𝑥 : COUNT(DISTINCT ...) should distinguish BIT-valued arguments by their logical values. 𝑂𝑓𝑖𝑥 : COUNT(DISTINCT x) equals the number of distinct logical BIT values in each group (x: BIT).

𝑛𝑓𝑎𝑢𝑙𝑡 : COUNT 𝑆𝑘𝑒𝑦 : SELECT COUNT(DISTINCT b) FROM t1 GROUP BY a; 𝑃𝑓𝑎𝑖𝑙 : Incorrect DISTINCT aggregation over BIT-valued arguments.

Orchestrator Instructions

𝑄

𝛥 1. Cross-check 𝑛𝑓𝑎𝑢𝑙𝑡 and 𝑛𝑓𝑎𝑢𝑙𝑡 to determine whether they refer to the same SQL construct. 2. If they agree, confirm 𝑛𝑓𝑎𝑢𝑙𝑡 and synthesize the final Bug Profile. 3. If they conflict, return the conflicting findings to the two analyzers for re-analysis.

Bug Profile 𝛹

Example output

Trigger Profile

Validation Profile

𝑛𝑓𝑎𝑢𝑙𝑡

COUNT

𝑃𝑓𝑎𝑖𝑙

Incorrect DISTINCT aggregation over BIT-valued arguments.

𝑆𝑘𝑒𝑦

SELECT COUNT(DISTINCT b) FROM t1 GROUP BY a;

𝐶𝑓𝑖𝑥

COUNT(DISTINCT ...) should distinguish BIT-valued arguments by their logical values.

𝑆𝑜𝑟𝑖𝑔

Regression test 𝑄

𝑂𝑓𝑖𝑥

COUNT(DISTINCT x) equals the number of distinct logical BIT values in each group (x: BIT).

Fig. 3. Bug Profile Construction.

3.1

Bug Profile Construction

Turning fixes into probes requires lifting path-local repair evidence into sibling-oriented bug knowledge. Our key insight is that historical fixes encode bug knowledge in a path-specific form while sibling testing requires transforming this local evidence into reusable sibling-oriented knowledge for Sibling Test Generation and Sibling Bug Validation. To support this transition, Reaper organizes the historical evidence into a structured Bug Profile Ψ. Before describing how Ψ is constructed, we first define what it contains and why each part is needed for sibling testing. Definition 4 (Bug Profile). We define the Bug Profile as Ψ = ⟨𝑇 , 𝑉 ⟩, where 𝑇 is the trigger profile and 𝑉 is the validation profile. The trigger profile is defined as 𝑇 = ⟨𝑛 fault , 𝑆 key , 𝑆 orig ⟩, where 𝑛 fault is the bug-triggering construct whose execution reaches the code fixed by the historical fix, 𝑆 key is the key statement in the regression test that contains the 𝑛 fault , and 𝑆 orig is the complete regression test. The validation profile is defined as 𝑉 = ⟨𝑃fail , 𝐶 fix , 𝑂 fix ⟩, where 𝑃fail is the failure pattern, 𝐶 fix is the fix-derived criterion, expressed as a specification of expected SQL behavior inferred from the patch and bug description, and 𝑂 fix is the fix-derived oracle, specifying a checkable condition or relation for determining incorrect execution behavior under the conditions specified in the oracle. The trigger profile provides the historical context needed for Sibling Test Generation. 𝑛 fault identifies the bug-triggering construct whose syntactic siblings are selected for testing, while 𝑆 key provides the statement containing that construct and the surrounding SQL structure needed for mutation. 𝑆 orig retains the complete regression test, including the object definitions, data and session settings needed to expose the historical bug. Together, these components allow sibling tests to exercise a different construct while preserving the bug-triggering conditions. The validation profile provides three complementary checks for Sibling Bug Validation. 𝑃fail supports matching the failure pattern across their executions. 𝐶 fix provides the specification inferred from the historical fix, whose applicability is assessed using the selected sibling’s SQL semantics and

Fix One, Miss Another: Leveraging Historical Bug Fixes to Uncover Residual Bugs in Database Systems

7

execution context. 𝑂 fix provides a concrete condition or relation for checking whether the candidate execution is incorrect under the stated conditions. The validation profile provides task-specific context for LLM-based reasoning about sibling bugs and improves the accuracy of sibling-bug detection by reducing false positives caused by valid semantic differences between sibling constructs. Bug Profile construction. Constructing an accurate Bug Profile from a historical fix is challenging for two reasons. (i) It is difficult to pinpoint the bug-triggering construct because the observed failure reflects the interaction of multiple SQL constructs and their context. In Figure 3, the incorrect result involves COUNT, DISTINCT, GROUP BY, and a BIT-typed argument. The description emphasizes BIT representation, and the patch introduces special handling for FIELD_TYPE_BIT. These clues explain the circumstances of the failure, but their prominence can lead an LLM to select a triggering condition rather than the construct corresponding to the repaired handler. For example, selecting DISTINCT instead of COUNT would change which sibling handlers are subsequently tested. (ii) It is difficult to recover the fix-derived oracle because a patch records the concrete repair mechanism, leaving the restored SQL behavior implicit. In Figure 3, the patch converts BIT values to BIGINT in temporary tables, while the failure manifests as an incorrect result under DISTINCT. The explicit type conversion can therefore draw an LLM toward implementation details and obscure the expected behavior: DISTINCT should preserve the complete logical BIT value. To address these challenges, Reaper employs three collaborating LLM agents to construct the Bug Profile. For the first challenge, Reaper adopts a cross-checking mechanism over independently 𝑄 inferred bug-triggering constructs. The Query Analyzer infers 𝑛 fault from the original regression test 𝑄 and the bug description 𝐷, while the Patch Analyzer maps the repaired handler in the code Δ . The Orchestrator confirms 𝑛 patch Δ to its corresponding SQL construct, yielding 𝑛 fault fault only when the two results refer to the same SQL construct, thereby reducing the possibility of selecting a surrounding trigger condition. For the second challenge, Reaper designs the Patch Analyzer instructions to introduce intermediate reasoning steps between the concrete code change and the validation profile. These steps guide the derivation of 𝐶 𝑓 𝑖𝑥 and 𝑂 𝑓 𝑖𝑥 from 𝐷 and Δ. Query Analyzer. The Query Analyzer aims to recover the SQL-side information from the regression 𝑄 test 𝑄 and bug description 𝐷. To identify 𝑛 fault , Reaper designs instructions (shown in Figure 3) that direct the LLM to use the diagnostic clues in 𝐷 to distinguish the bug-triggering construct in 𝑄 from surrounding trigger conditions. The instructions further require the analyzer to preserve 𝑄 the complete regression test as 𝑆 orig , extract the complete statement containing 𝑛 fault as 𝑆 key , and abstract the incorrect behavior described by 𝑄 and 𝐷 into the failure pattern 𝑃 fail . In Figure 3, although COUNT, DISTINCT, GROUP BY, and the BIT-typed argument all appear in the failing query, 𝑄 the instructions direct the analyzer to identify COUNT as 𝑛 fault . Patch Analyzer. The Patch Analyzer aims to recover the repair-side information from the bug Δ description 𝐷 and code patch Δ. To obtain both 𝑛 fault and the validation profile, Reaper designs the instructions with intermediate reasoning steps. Specifically, the analyzer first traces the reΔ . It then interprets the code paired handler in Δ to its corresponding SQL construct, yielding 𝑛 fault change together with the information in 𝐷 and infers 𝐶 fix as a specification of the expected SQL behavior. The instructions also direct the analyzer to identify the conditions and formulate 𝑂 fix as a checkable condition or relation for determining incorrect execution behavior. In Figure 3, the modification to Item_sum_count_distinct::setup() is mapped to COUNT. By analyzing the BIT(N) representation described in 𝐷 together with the BIT-to-BIGINT change in Δ, the analyzer infers that COUNT(DISTINCT ...) should distinguish BIT-valued arguments by their logical values. Orchestrator. The Orchestrator coordinates the two analyzers through the cross-checking mech𝑄 Δ anism. Specifically, it compares 𝑛 fault and 𝑛 fault together with their corresponding findings and

8

Yankai Rong, Zhaoyang Zhang, Shuang Liu, Wei Lu, and Xiaoyong Du

Algorithm 1 Sibling Test Generation 1: input Trigger Profile 𝑇 = ⟨𝑛 fault , 𝑆 key , 𝑆 orig ⟩ , grammar graph G𝛿

2: output Sibling tests Q 3: ast ← Parse (𝑆 key ) 4: anchor ← MatchConstruct (ast, 𝑛 fault ) 5: 𝐴 := 𝛼 ← AssociatedProduction (anchor, G𝛿 ) 6: C ← CollectSiblingAlternatives (𝐴, G𝛿 , 𝑛 fault ) 7: Q ← ∅ 8: for all 𝑞 ∈ C do 9: fragment ← InstantiateAlternative (𝑞, anchor ) 10: 𝑄 skel ← SubstituteOccurrence (𝑆 key , anchor, fragment ) 11: 𝑄 ′ ← Concretize (𝑄 skel , 𝑆 orig , G𝛿 ) 12: if 𝑄 ′ ≠ ⊥ then 13: Q ← Q ∪ {𝑄 ′ } 14: end if 15: end for 16: return Q

Original Query SELECT (WITH x(x) AS (SELECT 1) SELECT * FROM x WHERE (NEXTVAL(x))); AST / sibling alternatives

select_stmt with_clause

query_specification

with_list

expr

select_list

common_table_expr

where_clause

column_..._expr SETVAL_SYM

NEXTVAL_SYM Project

x

...

x

reused

1

Fill

Concretizer

Projected Query SELECT (WITH x(x) AS (SELECT 1) SELECT * FROM x WHERE (SETVAL(x, 1)));

Fig. 4. Sibling Test Generation.

confirms 𝑛 fault when the two analyses refer to the same SQL construct. When they disagree, the Orchestrator returns the conflicting findings to the analyzers for re-analysis and filters out fixes whose disagreement remains unresolved. After confirming 𝑛 fault , it constructs the trigger profile from 𝑆 orig , 𝑆 key , and 𝑛 fault , and the validation profile from 𝑃fail , 𝐶 fix , and 𝑂 fix . Together, the two profiles constitute the final Bug Profile Ψ. 3.2

Sibling Test Generation

With the trigger profile recovered from a historical fix, Reaper extends testing from the reported construct to its syntactic siblings while retaining the context that makes the historical bug relevant. The challenge is to redirect execution to a sibling handler while preserving the bug-triggering conditions inherited from the historical test. To achieve this, Reaper applies Grammar-Guided Sibling Mutation to identify grammar-defined siblings and construct statement skeletons through localized substitution. Guided by the trigger profile, an LLM-based Concretizer then performs Trigger-Constrained Concretization to complete these skeletons with sibling-specific operands, bindings, and execution requirements while preserving the historical bug-triggering context. 3.2.1 Grammar-Guided Sibling Mutation. Reaper uses the syntactic-sibling relation defined in §2 to identify alternatives to the bug-triggering construct 𝑛 fault recorded in the trigger profile. Algorithm 1 summarizes the complete sibling test generation procedure. To support sibling discovery, Reaper represents the target DBMS grammar as a grammar graph G𝛿 , where production alternatives are connected through the nonterminals they reference. Given the trigger profile 𝑇 and G𝛿 , Reaper locates the occurrence of 𝑛 fault associated with the historical failure in the AST of 𝑆 key and maps it to the corresponding grammar production 𝐴 := 𝛼. Starting from the alternative productions of 𝐴, Reaper performs a breadth-first search (BFS) that expands unit productions but does not descend into the internal nonterminals of concrete constructs (Line 6). A concrete alternative is retained as a sibling candidate if its construct differs from 𝑛 fault . Each production is processed at most once, and the search terminates when the queue is empty. For each sibling alternative, Reaper uses its production as the structural template for a replacement fragment. InstantiateAlternative matches nonterminal occurrences by symbol and occurrence order, filling matched occurrences with the corresponding historical subtrees unchanged. Unmatched nonterminal occurrences remain as placeholders for sibling-specific components. The fragment then replaces only the selected historical occurrence in 𝑆 key to obtain the statement skeleton 𝑄 skel (Line 10). This local replacement preserves both the historical subtrees reused within the fragment and the surrounding statement structure outside it. The complete regression test 𝑆 orig

Fix One, Miss Another: Leveraging Historical Bug Fixes to Uncover Residual Bugs in Database Systems

9

is passed separately to the Concretizer, which uses the historical setup and execution context to complete the skeleton and satisfy sibling-specific semantic requirements. Figure 4 illustrates this process for NEXTVAL. The grammar identifies SETVAL as a sibling construct. Since both alternatives contain table_ident, Reaper reuses the historical subtree x. The additional value expression required by SETVAL has no historical counterpart and is left as a placeholder, yielding SETVAL(x, □). Replacing the selected NEXTVAL(x) occurrence with this fragment produces the sibling statement skeleton while preserving the historical bug-triggering conditions. 3.2.2 Trigger-Constrained Concretization. Reaper employs an LLM-based Concretizer to complete the sibling statement skeleton 𝑄 skel (Line 11). The Concretizer receives the skeleton constructed from 𝑛 fault and 𝑆 key , together with the complete historical regression test 𝑆 orig from the trigger profile. The skeleton specifies the selected sibling and its unresolved components, while 𝑆 orig provides the historical statements, definitions, and bindings required to complete the sibling test without discarding the historical bug-triggering context. The Concretizer first compares 𝑄 skel with 𝑆 key to identify the operands and additional requirements introduced by the sibling construct. For unresolved components, it consults the grammar graph G𝛿 to restrict their completion to alternatives permitted by the corresponding grammar productions. It then examines 𝑆 orig to determine which definitions and bindings are used by the reused subtrees and must therefore be retained. Based on this information, the Concretizer completes the unresolved components while introducing new elements only where required by the sibling construct. A completion is accepted only if it conforms to the grammar and satisfies the additional requirements while retaining the statements and bindings relevant to the historical bug-triggering context; otherwise, the Concretizer returns ⊥ and the candidate is discarded. Figure 4 illustrates this process for SETVAL(x, □). The Concretizer first identifies the additional value argument required by SETVAL. It then examines 𝑆 orig and identifies that x refers to a CTE whose pure-alias binding is required to trigger the historical bug. Replacing x with an ordinary sequence name would satisfy the object requirement of SETVAL, but would remove this historical binding. The Concretizer therefore retains the CTE definition and its reference and supplies 1 for the unresolved value expression, yielding SETVAL(x, 1). 3.3

Sibling Bug Validation

Syntactic siblings may implement different semantics and consequently produce different valid results. Sibling bug validation therefore requires semantic reasoning about the execution result of a sibling test 𝑄 ′ , beyond direct comparison with the historical execution result. LLMs can support this reasoning using their knowledge of SQL semantics and open-source DBMS implementations. However, such general knowledge alone may be insufficient for judging a particular sibling test. Without information specific to the historical bug, the model may rely on unsupported assumptions about the selected sibling and its execution result. To provide a basis for these judgments, Reaper uses the Validation Profile 𝑉 = ⟨𝑃fail , 𝐶 fix , 𝑂 fix ⟩ recovered from the historical fix to guide three LLM agents. Each agent follows intermediate reasoning steps organized around the corresponding profile component. The three judgments serve distinct purposes. The first uses 𝑃fail to restrict validation to executions exhibiting the historical failure pattern. The second uses 𝐶 fix to assess whether the specification recovered from the historical fix applies to the selected sibling. The third evaluates 𝑂 fix to establish whether the execution result is incorrect under the conditions specified in the oracle, since criterion applicability alone does not establish incorrect execution behavior. Figure 5 uses MariaDB MDEV-33496 to illustrate the validation process. The historical bug occurs when CREATE TABLE ... AS SELECT derives a result column for AVG(YEAR(a)). The implementation did not correctly account for the range of

10

Yankai Rong, Zhaoyang Zhang, Shuang Liu, Wei Lu, and Xiaoyong Du

Validation Profile Pfail — Failure pattern

Cfix — Fix-derived criterion

Ofix — Fix-derived oracle

CREATE TABLE ... AS SELECT raises ERROR 1264 when storing the result of AVG over a valid temporal-function output.

CREATE TABLE ... AS SELECT should preserve the computed AVG result for valid temporal-function outputs when inferring the result-column type.

For AVG over a non-negative datetime component, the integer capacity of the inferred DECIMAL type must be no smaller than that required by the resulting value.

I Match Failure Pattern Input:

Pfail + Q′ + execution result

Instructions

II Check Criterion Applicability Input:

Cfix + Q′

III Check Oracle Violation Input:

Ofix + Q′ + execution result

1. Identify the failure pattern specified by Pfail.

Instructions 1. Identify the specification in Cfix.

2. Examine the corresponding behavior in the execution result.

2. Examine the selected sibling’s semantics with its use in Q'.

3. Determine whether Q′ exhibits Pfail.

3. Assess whether Cfix applies to the selected sibling in Q'.

Instructions 1. Check the conditions specified in Ofix against Q' and its execution result. 2. Compare the condition or relation in Ofix with the corresponding execution result. 3. Determine whether the condition or relation in Ofix is violated.

(a) Running Example

(b) Running Example

(c) Running Example

Execution evidence:

Intermediate judgments:

Execution evidence:

CREATE TABLE r_todays AS SELECT AVG(TO_DAYS(a)) AS v FROM t; ERROR 1264: Out of range value for column 'v' ...

Intermediate judgments: • CREATE … fails with an out-of-range error. • ERROR 1264 matches the historical failure pattern.

Output:

Vsym = true

(MATCH)

• Cfix requires … to preserve the computed AVG result for valid temporal-function outputs.

ERROR 1264: Out of range value for column 'v' ...

• In Q', TO_DAYS(a) produces the value consumed by AVG under...

Intermediate judgments: • The conditions in Ofix hold for Q'.

• The specification in Cfix is therefore applies to TO_DAYS(a) in Q'.

• The error indicates that the inferred DECIMAL type cannot represent the resulting AVG value. • This execution is inconsistent with the capacity relation specified in Ofix.

Output:

Vcrit = true

(APPLICABLE)

Output:

Vorc = true

(VIOLATED)

Fig. 5. LLM-based Sibling Bug Validation guided by the validation profile.

non-negative datetime-component functions when deriving the DECIMAL type for AVG, producing a column with insufficient integer capacity and raising ERROR 1264 for otherwise valid inputs. The historical fix corrects the type handling for these functions so that the derived DECIMAL type can represent the resulting value. Starting from this fix, Reaper generates a sibling test by replacing YEAR(a) with TO_DAYS(a) and validates its execution using the recovered validation profile. Stage I: Match Failure Pattern. The first agent determines whether the execution result of 𝑄 ′ exhibits the historical failure pattern, restricting further validation to candidates relevant to the historical bug. Given 𝑃fail , 𝑄 ′ , and its execution result, the prompt guides the agent through three reasoning steps. First, the agent identifies the failure pattern specified by 𝑃fail . Second, it examines the corresponding behavior in the execution result. Finally, it determines whether 𝑄 ′ exhibits 𝑃fail based on these intermediate judgments. The comparison considers the failure described by the pattern and the operation in which it occurs, without requiring identical concrete outputs. In Figure 5(a), 𝑃fail describes ERROR 1264 when CREATE TABLE ... AS SELECT stores an AVG result. The agent identifies an out-of-range error in the execution of the statement containing AVG(TO_DAYS(a)) and relates this error to the historical failure pattern. It therefore returns Match, for which 𝑉sym (𝑄 ′ ) is true. A No_Match decision excludes the candidate from further validation. Stage II: Check Criterion Applicability. The second agent determines whether the specification in 𝐶 fix applies to the selected sibling. This judgment is necessary because a matching failure pattern does not establish that the fix-derived criterion is applicable to the sibling’s semantics. Given 𝐶 fix and 𝑄 ′ , the prompt first directs the agent to identify the specification in 𝐶 fix . Second, the agent examines the selected sibling’s semantics together with its use in 𝑄 ′ . Finally, it assesses whether the specification applies to the selected sibling in that statement. In Figure 5(b), 𝐶 fix specifies that

Fix One, Miss Another: Leveraging Historical Bug Fixes to Uncover Residual Bugs in Database Systems

11

Table 1. Unknown bugs found by Reaper. Database System

Crash/Fatal Bugs

Logic Bugs

Total

Pending

Confirmed

Fixed

Pending

Confirmed

Fixed

MariaDB MySQL OceanBase CockroachDB

0 0 0 0

4 0 2 5

1 0 0 1

0 0 3 1

19 15 4 8

2 1 0 8

23 15 9 14

Total

0

11

2

4

46

11

61

CREATE TABLE ... AS SELECT should preserve the computed AVG result for valid temporal-function outputs when inferring the result-column type. The agent identifies that TO_DAYS(a) produces the values consumed by AVG within CREATE TABLE ... AS SELECT. It therefore concludes that the specification applies to this use of TO_DAYS(a) and returns Applicable, for which 𝑉crit (𝑄 ′ ) is true. A Not_Applicable decision excludes the candidate from the next stage. Stage III: Check Oracle Violation. The third agent determines whether the execution result violates the condition or relation specified in 𝑂 fix . Given 𝑂 fix , 𝑄 ′ , and its execution result, the prompt organizes the judgment into three reasoning steps. First, the agent checks the conditions specified in 𝑂 fix against 𝑄 ′ and its execution result. Second, it compares the condition or relation in 𝑂 fix with the corresponding execution result. Finally, it assesses the oracle result based on the condition checks and evaluation. In Figure 5(c), 𝑂 fix requires that, for AVG over a non-negative datetime component, the integer capacity of the inferred DECIMAL type be no smaller than that required by the resulting value. In the illustrated reasoning, the agent first determines that the conditions in 𝑂 fix hold for 𝑄 ′ . It then interprets the out-of-range error as indicating that the inferred DECIMAL type cannot represent the resulting AVG value. On this basis, the agent concludes that the inferred integer capacity is smaller than that required by the result and returns Violated. Accordingly, 𝑉orc (𝑄 ′ ) is true only when the conditions hold and the agent determines that the condition or relation in 𝑂 fix is violated. Reaper reports a sibling bug only when the three agents return Match, Applicable, and Violated, respectively: Report(𝑄 ′ ) ⇔ 𝑉sym (𝑄 ′ ) ∧ 𝑉crit (𝑄 ′ ) ∧ 𝑉orc (𝑄 ′ ).

4

(1)

Evaluation

To evaluate the effectiveness of Reaper in detecting sibling bugs in real-world DBMSs, we address the following four research questions: • RQ1: How effective is Reaper at discovering sibling bugs in real-world DBMSs? • RQ2: How does Reaper compare with existing DBMS fuzzers? • RQ3: How do Reaper’s key test-generation components contribute to sibling-bug discovery? • RQ4: How effectively does Reaper distinguish logic sibling bugs from benign behavior? 4.1

Evaluation Setup

4.1.1 Environment. We conducted all experiments on a machine running 64-bit Ubuntu 22.04.5 LTS, equipped with an Intel(R) Xeon(R) Gold 6454S CPU with 128 cores and 512 GB of RAM. All LLM-based components in Reaper use DeepSeek-V4-Flash through its official API.

12

Yankai Rong, Zhaoyang Zhang, Shuang Liu, Wei Lu, and Xiaoyong Du

1 CREATE TABLE empty (k INT 2 PRIMARY KEY); 3 BEGIN; 4 DECLARE foo CURSOR WITH HOLD 5 FOR SELECT * FROM empty; 6 COMMIT; 7 FETCH ABSOLUTE 1 FROM foo; 8 -- After fix: 9 -no internal error

1 SELECT make_date( 2 0, -- year 3 11, -- month 4 11 -- day 5 ); 6 -- After fix: 7 -ERROR: invalid year

1 CREATE TABLE t (a INT, 2 KEY idx1 (a)); 3 INSERT INTO t VALUES (1); 4 CREATE VIEW v AS 5 SELECT /*+ NO_INDEX(t idx1) */ 6 a FROM t; 7 SHOW CREATE VIEW v; 8 -- After fix: 9 -NO_INDEX hint preserved

10 CREATE TABLE empty (k INT 11 PRIMARY KEY); 12 BEGIN; 13 DECLARE foo CURSOR WITH HOLD 14 FOR SELECT * FROM empty; 15 COMMIT; 16 FETCH FIRST FROM foo; 17 -- Observed: internal error 18 -SQLSTATE XX000

8 SELECT make_timestamp( 9 2013, -- year 10 13, -- month 11 15, -- day 12 0, 0, 0 -- hour/min/sec 13 )::string; 14 -- Observed: 15 -2014-01-15 00:00:00 16 -- Expected: ERROR

10 CREATE TABLE t (a INT); 11 INSERT INTO t VALUES (1); 12 CREATE VIEW v AS SELECT 13 /*+ MAX_EXECUTION_TIME(1) */ 14 SLEEP(0.05) AS s, a FROM t; 15 SELECT s FROM v; 16 -- Observed: succeeds; hint lost 17 -- Expected: ERROR 1969 18 -(query interrupted)

(a) A residual FETCH FIRST bug in CockroachDB (Bug #171238).

(b) A residual domain-validation bug in CockroachDB (Bug #173599).

(c) A residual hint-preservation bug in MariaDB (Bug #39946).

Fig. 6. Representative sibling bugs discovered by Reaper. Each column compares a repaired historical query with its sibling test that exposes a residual bug.

4.1.2 Target Databases. We evaluate Reaper on four production-grade relational DBMSs: MySQL (v9.6.0), MariaDB (v13.2), OceanBase (v4.5.1), and CockroachDB (v26.3.0). The selected systems cover both centralized and distributed architectures and differ in their SQL grammar and execution implementations, allowing us to evaluate Reaper across heterogeneous DBMS designs. The coverage comparison is conducted on MySQL, MariaDB, and OceanBase. CockroachDB is excluded because its branch coverage could not be measured under the same instrumentation setup. 4.1.3 Baselines. We compare Reaper against three state-of-the-art DBMS testing approaches: SQLancer [22–24], Squirrel [29], and Argus [16]. These baselines represent complementary strategies for DBMS testing, including generation-based testing, structure-aware mutation, and LLMassisted oracle discovery and test generation. SQLancer generates queries from scratch and detects logic bugs using DBMS testing oracles such as TLP [23] and NoREC [22]. In our experiments, we use TLP for MySQL and NoREC for the remaining DBMS targets. Squirrel is a mutation-based fuzzer that translates seed queries into an intermediate representation and applies structure-aware mutations to explore new execution paths. Argus uses LLMs to propose pairs of equivalent Constrained Abstract Queries (CAQs), verifies their equivalence using a SQL equivalence solver, and instantiates the verified pairs with reusable SQL snippets to generate concrete test cases [16]. 4.1.4 Historical Bug Corpus. To construct the historical bug corpus, we mine bug-fixing commits from the GitHub repositories of the four target DBMSs and retain commits for which the artifacts required by Bug Profile Construction can be recovered. For each retained commit, we extract the associated description, regression test, and code patch. In total, this collection stage yields 4,487 historical bug-fixing commits: 1,713 from MySQL, 1,139 from OceanBase, 1,112 from MariaDB, and 523 from CockroachDB. These commits form the input corpus for Bug Profile Construction. 4.2

RQ1: Effectiveness in Sibling-Bug Discovery

Overall results. Reaper discovered 61 previously unknown sibling bugs across the four evaluated DBMSs: 23 in MariaDB, 15 in MySQL, 9 in OceanBase, and 14 in CockroachDB. As summarized in Table 1, 57 bugs have been confirmed by upstream developers, of which 13 have already been fixed, while the remaining 4 are still under analysis. Notably, a single historical fix can expose residual bugs in multiple sibling handlers. For example, starting from the historical fix for NEXTVAL, Reaper

Fix One, Miss Another: Leveraging Historical Bug Fixes to Uncover Residual Bugs in Database Systems

Reaper (38) SQLancer (7) Squirrel (0) Argus (1)

0 0

0

0

13

0 0

38

0

7

0

0

0

0 0

1

Fig. 7. The distribution of unique bugs detected by Reaper and the baselines.

exposed the same residual issue in both LASTVAL and SETVAL. We conservatively consolidate such manifestations when they correspond to the same underlying bug, so they are counted as one sibling bug rather than multiple discoveries. Hence, the 61 bugs represent distinct reported bugs, while the affected sibling handlers and triggering tests are more numerous, demonstrating that Reaper can extend a localized historical fix to systematically uncover unpatched behavior across its sibling handlers. Beyond the reported bugs, Reaper extends each historical regression test from the repaired construct to its grammar-defined sibling set. Under the recovered bug-triggering context, the generated sibling tests enable systematic validation of the related sibling handlers for the same historical bug. This turns a regression test for a single repaired construct into a sibling-level regression task, allowing the original test and its generated sibling tests to be executed together in existing regression-testing and CI workflows. Bug Significance and Impact. The reported bugs span silently incorrect results, crashes, and fatal internal errors. Their upstream severity assessments and subsequent fixes further indicate their practical impact. All 15 MySQL bugs listed in Table 1 carry Oracle’s S3 severity rating, while most confirmed MariaDB bugs were rated major. Thirteen bugs have already been patched upstream. MariaDB Bug #39063 provides a representative example of a sibling bug. The historical bug affected NEXTVAL, where the corresponding repair introduced a table_list->is_pure_alias() check. Reaper subsequently exposed the same missing handling in the LASTVAL and SETVAL sibling handlers. MariaDB upgraded the report from major to critical, and the developer explicitly referred to the historical NEXTVAL repair when suggesting the fix: “try adding the table_list->is_pure_alias() block to Item_func_setval::val_int, same as Item_func_nextval::val_int? Add a test case appended to where the previous fix was and create a pull request.” Cross-version reproduction further indicates that some sibling bugs remain present across multiple maintained releases. For Bug #39598, a MariaDB developer reproduced the issue on four versions: “I could reproduce the issue with testcase provided in report on mariadb 10.11, 11.4, 11.8 and 12.3. . . This inconsistency occurs in the error path and can break tools or scripts that expect a uniform format in the Table column. Attached the mtr test to repro.” Notably, MariaDB 10.11 became generally available in February 2023, showing that the issue remained present across release lines spanning more than three years. Several reports also received rapid upstream responses. For CockroachDB Bug #171234, the developer took ownership of the report on the day of disclosure and identified the missing guard in both width_bucket overloads: “Taking this up. The guard is missing from both the numeric and int overloads of width_bucket in pkg/sql/sem/builtins/math_builtins.go. Will open a draft PR shortly.” An upstream fix was submitted on the following day. Bug Diversity. The 61 sibling bugs cover a broad range of failure manifestations and DBMS components. Among them, 50 are logic bugs that complete execution but manifest in diverse forms of incorrect behavior, while the remaining 11 result in crashes or fatal internal errors. These bugs arise across multiple stages of DBMS processing, including query analysis, optimization,

14

Yankai Rong, Zhaoyang Zhang, Shuang Liu, Wei Lu, and Xiaoyong Du

temporary-table processing, execution, and built-in routines. To better illustrate the diversity of these sibling bugs, we present three representative cases showcasing the different implementation locations and validation conditions encountered by Reaper. Specifically, the selected cases span cursor handling, datetime construction, and hint preservation across different DBMS components and failure manifestations. Implementation-location diversity. The three cases show how a historical regression test can leave related handlers untested across different implementation structures. In Figure 6(a), FETCH ABSOLUTE and FETCH FIRST reach separate cursor-dispatch branches. Discovering the residual bug requires changing the cursor operation while retaining the empty-table, WITH HOLD, and cross-transaction conditions. Grammar-Guided Sibling Mutation performs this localized substitution, directing the historical trigger to the sibling branch that lacks the check. In Figure 6(b), the missing validation occurs in a different built-in routine: make_timestamp accepts an out-of-domain calendar component even though the historical fix corrected such handling in make_date. Here, sibling selection identifies the target routine, while Trigger-Constrained Concretization supplies its additional time arguments without removing the bug-triggering condition. In Figure 6(c), the two hints follow different handling paths during view creation. The Concretizer supplies the time limit and delay needed to exercise MAX_EXECUTION_TIME, while retaining the historical view-creation context. Across these cases, the syntactic-sibling relation determines which alternative handler to test, and the trigger profile constrains the sibling tests to retain the conditions relevant to the bug. Validation-condition diversity. The contrast among the three cases illustrates why direct differential comparison with the historical execution result is insufficient for validating sibling bugs. In Figure 6(a), the sibling exposes an internal error under the preserved bug-triggering conditions, allowing Stage I to associate the execution with the historical bug through 𝑃fail . The other two cases are more subtle because the sibling executions complete successfully. In Figure 6(b), the concrete input changes from year=0 to month=13, and make_timestamp naturally produces a different form of result from make_date. Comparing their concrete outputs would therefore provide no useful oracle. Instead, Stage II establishes that 𝐶 fix also applies to the sibling, while Stage III uses 𝑂 fix to determine that returning a normalized timestamp for an out-of-domain calendar component is incorrect. A similar issue appears in Figure 6(c): NO_INDEX and MAX_EXECUTION_TIME have different semantics, so their execution results are not expected to be identical. Reaper instead checks whether 𝐶 fix applies to the sibling hint and then uses 𝑂 fix to determine whether the hint is preserved and takes effect. These cases show that the staged validation does not require a sibling test to reproduce the historical execution result; it uses the Validation Profile to determine whether the sibling execution represents the same bug under its own semantics. 4.3

RQ2: Baseline Comparison

To assess the effectiveness of Reaper, we compare it with three state-of-the-art DBMS testing methods: SQLancer, Sqirrel, and Argus. These baselines represent complementary testing paradigms, including query generation, mutation-based exploration, and LLM-guided test synthesis. Each tool runs for 8 hours per target DBMS on identical hardware, using the same seeds when required and its default configuration without additional tuning. We measure bug-finding effectiveness by the number of unique bugs discovered in the controlled comparison. We additionally record branch coverage as well as syntactic and semantic validity to characterize the explored execution space. Bug-Finding Capability. Figure 7 summarizes the unique bugs discovered in the controlled comparison. Reaper discovers 38 bugs, compared with 7 for SQLancer, 1 for Argus, and none for Sqirrel, with no overlap between Reaper and the baselines. The key distinction lies in the defect space targeted by each approach. Existing approaches explore a general SQL input space through generation or mutation, whereas Reaper replaces the historical bug-triggering construct

Fix One, Miss Another: Leveraging Historical Bug Fixes to Uncover Residual Bugs in Database Systems

15

100 140

250 80

120

200

100

60

150

80 40

60 SQUIRREL SQLancer Argus Reaper

40 20 0

0

1

2

3

4

5

6

7

100 SQUIRREL SQLancer Argus Reaper

20 0

8

0

1

(a) MySQL

2

3

4

5

6

7

SQUIRREL SQLancer Argus Reaper

50 0

8

0

1

(b) MariaDB

2

3

4

5

6

7

8

(c) OceanBase

Fig. 8. Code branch coverage (k) on MySQL, MariaDB, and OceanBase.

SQUIRREL 99 99 98

100

SQLancer

Argus

99 99 98

98 98 97

SQUIRREL

Reaper

87

semantic valid (%)

syntax valid (%)

84

80

73 66

60 40

80

0

(a) Syntactic validity

CockroachDB

88 81

63

63 51

52

43 26

0

OceanBase

Reaper

74

73

40 20

MariaDB

Argus

86

73

60

20 MySQL

SQLancer

100

99 99 97

18

15

MySQL

MariaDB

OceanBase

CockroachDB

(b) Semantic validity

Fig. 9. Syntactic and semantic validity of generated sibling tests.

with its syntactic siblings while preserving the associated bug-triggering context. Consequently, its search is concentrated on handlers that are structurally related to a repaired path but may not have received the same fix. This Bug-Profile-guided sibling testing exposes residual inconsistencies that general-purpose generation and mutation do not explicitly target. Code Coverage. Figure 8 shows branch-coverage growth on MySQL, MariaDB, and OceanBase over the 8-hour campaigns. We exclude CockroachDB due to the instrumentation limitation discussed in Section 4.1. Reaper achieves higher branch coverage than all baselines on all three systems throughout each campaign and finishes at approximately 151K, 98K, and 274K branches on MySQL, MariaDB, and OceanBase, respectively. By comparison, the strongest baseline Argus reaches 133K, 86K, and 222K; SQLancer reaches 118K, 76K, and 197K; and Sqirrel reaches 65K, 63K, and 165K. Relative to the strongest baseline on each system, these final coverage values correspond to gains of 13.5%, 14.0%, and 23.4%. The additional coverage reached by Reaper reflects its ability to traverse implementation paths associated with repaired constructs and their syntactic siblings. These paths are not merely uncovered SQL features; they represent alternative handlers that may share the repaired requirement but evolve inconsistently during maintenance. Manual inspection of the final coverage profiles further shows that Reaper’s coverage is complementary to, rather than a strict superset of, the baselines’. While some regions covered by the baselines remain uncovered by Reaper, it also reaches branches that none of them exercise. The key difference lies in the dimension along which execution paths are explored: instead of broadly exploring the SQL input space, Reaper replaces the historical construct with its syntactic siblings while preserving the associated bug-triggering context. This changes the exercised handler without discarding the context implicated in the historical bug. As a result, sibling mutation reaches additional implementation paths in components such as optimization, expression resolution, and statement preparation, explaining the complementary coverage observed in the profiles.

16

Yankai Rong, Zhaoyang Zhang, Shuang Liu, Wei Lu, and Xiaoyong Du

Table 2. Ablation study: unique bugs discovered by Table 3. Ablation of sibling-bug validation on the cueach Reaper configuration. rated benchmark.

DBMS

Reaper

Reaper −𝑛fault Reaper−conc

Configuration

Acc. Prec. Rec.

F1 50.0 64.2 72.7 78.0

MariaDB MySQL OceanBase CockroachDB

12 7 9 10

0 0 0 1

2 0 1 2

LLM-only Historical Diff + LLM + Stage I (match 𝑃 fail ) + Stage II (apply 𝐶 fix )

46.9 61.2 75.5 81.6

38.2 48.6 61.5 69.6

72.2 94.4 88.9 88.9

Total

38

1

5

Full Reaper (+ 𝑂 fix )

87.8

80.0 88.9 84.2

SQL Validity. Reaching deeper DBMS logic requires generated queries to remain valid beyond parsing. Figure 9 reports the syntactic validity across the four evaluated DBMSs and the semantic validity on MySQL, MariaDB, and OceanBase. Reaper maintains consistently high syntactic validity, reaching 98% on MySQL and MariaDB and 97% on OceanBase and CockroachDB. SQLancer and Argus are slightly higher at 98–99%. The small gap mainly arises from the additional concretization performed by Reaper: although sibling statement skeletons are derived from the DBMS grammar, completing sibling-specific operands and context can occasionally produce queries rejected by the parser. More importantly, Reaper achieves substantially higher semantic validity, reaching 87%, 86%, and 88% on MySQL, MariaDB, and OceanBase, respectively, compared with approximately 73% for SQLancer and 43–63% for Argus. Mutation-based Sqirrel achieves syntactic validity of 73%, 84%, and 66% and semantic validity of 15–26% on the three supported DBMSs. These results show that the modest syntactic cost introduced by concretization is accompanied by a substantial gain in semantic validity. By incorporating the historical query context, the Concretizer resolves sibling-specific bindings and operands while preserving the grammar-defined sibling structure, allowing more generated tests to exercise the intended sibling handlers. In summary, Reaper demonstrates stronger bug-finding capability than the baselines, while also achieving higher branch coverage and semantic validity with comparable syntactic validity. These results adequately answer RQ2. 4.4

RQ3: Ablation Study

We examine the two key components that enable sibling-bug discovery in Reaper: the identification of the bug-triggering construct 𝑛 𝑓 𝑎𝑢𝑙𝑡 , which guides grammar-guided sibling mutation, and trigger-constrained concretization, which resolves sibling-specific semantic requirements while preserving the bug-triggering context recovered from historical fixes. We compare full Reaper against Reaper−𝑛fault , which replaces the identified bug-triggering construct 𝑛 𝑓 𝑎𝑢𝑙𝑡 with a randomly selected mutable construct, and Reaper−conc , which removes the concretizer. All configurations use the same historical corpus, target DBMSs, and validation procedure. We evaluate the contribution of sibling bug validation separately in §4.5. Bug-triggering construct 𝑛 𝑓 𝑎𝑢𝑙𝑡 . The effectiveness of sibling test generation depends first on whether the bug-triggering construct 𝑛 𝑓 𝑎𝑢𝑙𝑡 can be identified reliably. As a direct LLM baseline, we provide the complete historical fix to a single LLM and ask it to identify 𝑛 𝑓 𝑎𝑢𝑙𝑡 in one pass; this achieves only 63.0% accuracy. In contrast, Reaper analyzes the fix from complementary query-side and repair-side views. The Query Analyzer and Patch Analyzer initially agree on 78.1% of the fixes, and the Orchestrator resolves disagreements for another 14.2%, while the remaining 7.7% are discarded when the two views remain inconsistent. Two authors independently inspected a random sample of 50 accepted Bug Profiles and judged the confirmed 𝑛 𝑓 𝑎𝑢𝑙𝑡 correct in 94.0% of

Fix One, Miss Another: Leveraging Historical Bug Fixes to Uncover Residual Bugs in Database Systems

17

them. These results show that cross-view analysis provides a substantially more reliable anchor for subsequent sibling testing while filtering localizations that cannot be consistently established. The ablation further shows why identifying 𝑛 𝑓 𝑎𝑢𝑙𝑡 is important. As shown in Table 2, Reaper−𝑛fault reduces the number of detected bugs from 38 to 1, with no bug found on MariaDB, MySQL, or OceanBase. Importantly, this variant still performs the same sibling mutation, concretization, and validation; the only difference is the construct selected for mutation. This result demonstrates that syntactic relatedness alone is insufficient for identifying defect-relevant sibling handlers. The historical fix provides the semantic context that connects syntactic siblings with the repaired behavior. Without this repair context, mutation may reach syntactically similar handlers but lacks evidence that these handlers are subject to the same repaired requirement. Trigger-constrained concretization. Reaper−conc retains the same 𝑛 𝑓 𝑎𝑢𝑙𝑡 and therefore the same defect-relevant sibling candidates, but exposes only 5 bugs compared with 38 for full Reaper. This contrast separates structural relevance from executable activation. Grammar-Guided Sibling Mutation can identify a related handler and construct a corresponding skeleton, but the selected sibling may introduce new operands, bindings, or execution requirements that are absent from the historical query. Without concretization, many such skeletons fail before the behavior of the selected sibling is exercised. Hence, grammar relations determine where to test, but do not by themselves provide the semantic conditions required to exercise the target handler. Taken together, the two ablations reveal a division of responsibility in Reaper’s test generation. Identifying the bug-triggering construct 𝑛 𝑓 𝑎𝑢𝑙𝑡 concentrates the search on defect-relevant sibling handlers, whereas trigger-constrained concretization enables those handlers to be exercised under a realizable test context. Removing either property substantially degrades bug discovery, showing that sibling testing requires both a bug-relevant target and a semantically valid sibling test. 4.5

RQ4: Effectiveness of Logic-Bug Validation

To evaluate Reaper’s logic-bug validation capability, we examine how reliably it distinguishes sibling-bug candidates. Curated validation benchmark. We construct a labeled benchmark to isolate the effectiveness of the three-stage validation in Section 3.3. The benchmark is not intended to estimate field precision; instead, it provides a fixed set on which different validation strategies can be compared under identical candidates. It contains upstream-confirmed sibling bugs, triaged logic candidates, controlled oracle-replay cases, and manually labeled benign projections. Each record contains the Bug Profile Ψ, the sibling query 𝑄 ′ , its execution outcome, and a human label. Crash and fatal-error candidates are excluded because this experiment focuses on logic-bug validation. In total, the benchmark contains 49 logic candidates, including 18 positives and 31 negatives (test cases show different but correct behavior from the fixed historical bug). Staged validation effectiveness. Table 3 compares configurations that progressively incorporate historical execution information and the three components of the Validation Profile: 𝑃 fail , the historical failure pattern; 𝐶 fix , the fix-derived criterion specifying expected SQL behavior; and 𝑂 fix , the fix-derived oracle specifying a checkable condition or relation under the conditions specified in the oracle. LLM-only, which classifies candidates using their execution outputs alone, achieves 46.9% accuracy, 38.2% precision, 72.2% recall, and 50.0% F1, misclassifying 21 of the 31 benign projections as bugs. Historical Diff + LLM additionally incorporates the historical and sibling execution outcomes, increasing recall to 94.4% and precision to 48.6%. It retains 17 of the 18 positive cases but still produces 18 false positives, indicating limited discrimination between sibling bugs and legitimate execution differences. Adding Stage I (match 𝑃fail ) requires the sibling execution to exhibit the historical failure pattern. False positives decrease from 18 to 10, increasing precision

18

Yankai Rong, Zhaoyang Zhang, Shuang Liu, Wei Lu, and Xiaoyong Du

to 61.5% and accuracy to 75.5%. Recall decreases from 94.4% to 88.9%, corresponding to one fewer retained positive case (17 to 16). The higher recall results from this relatively permissive decision, which preserves nearly all positive cases while also admitting many benign projections. Adding Stage II (apply 𝐶 fix ) checks whether the fix-derived criterion applies to the selected sibling. This further reduces false positives to 7 and increases precision to 69.6% and accuracy to 81.6%, while recall remains at 88.9%. Full Reaper additionally evaluates oracle violation using 𝑂 fix under the conditions specified in the oracle, reducing false positives to 4 and achieving 87.8% accuracy, 80.0% precision, 88.9% recall, and 84.2% F1. It retains 16 of the 18 positive cases and correctly rejects 27 of the 31 benign projections. Following failure-pattern matching, criterion-applicability and oracle-violation checking together increase precision from 61.5% to 80.0% without reducing recall. These results support the contribution of the validation profile to rejecting benign projections while retaining true sibling bugs.

5

Related Work

DBMS Fuzzing. DBMS fuzzing has been extensively studied for discovering bugs through automated SQL generation and mutation. Mutation-based fuzzers, including Squirrel [29], DynSQL [7], and SQLRight [13], evolve existing SQL seeds through AST-level, stateful, or coverageguided transformations. Generation-based approaches, such as SQLsmith [18], Polyglot [2], and SQLancer++ [31], synthesize SQL queries from grammars or adaptive generators. Other approaches introduce additional guidance through grammar-free testing, reusable semantic operations, queryplan exploration, coverage-guided traversal, and bug-pattern prioritization [1,4,12,28,29]. Recent DBMS testing approaches have also adopted LLMs to assist SQL generation. ShQveL [30] synthesizes SQL fragments to improve dialect coverage, while Argus [16] generates constrained abstract query pairs together with oracle templates. These approaches improve the diversity and complexity of generated SQL inputs, but primarily explore the general DBMS input space. They do not identify a bug-triggering construct from a historical fix and extend its triggering context to grammar-related sibling handlers. Reaper instead starts from a historical fix, recovers its Bug Profile, and uses the bug-triggering construct to direct testing toward sibling handlers that may contain residual sibling bugs. Test Oracles for DBMS Testing. Reliable DBMS testing requires effective oracles for determining whether an execution is incorrect. Metamorphic testing approaches, such as TLP [23] and NoREC [22], construct logically related query variants to detect inconsistent results. Differential execution approaches, including DQE [26], compare multiple executions under related inputs, while EET [8] and CODDTest [28] exploit expression-level equivalences. PINOLO [5] synthesizes approximate metamorphic relations, and Kangaroo [9] combines context-sensitive instantiation with multi-plan execution. Other approaches derive test oracles from configuration changes [10], cross-engine agreement [4], or executable SQL semantics [15]. These oracle mechanisms rely on predefined relations or specifications, such as semantic equivalence, differential consistency, configuration invariance, cross-engine agreement, or reference semantics. However, they cannot be directly applied to Sibling Bug Validation because execution differences between sibling and historical tests do not necessarily indicate a bug. Reaper instead derives the Validation Profile from the historical fix. 𝑃fail captures the historical failure pattern, 𝑂 fix provides the fix-derived oracle, and 𝐶 fix provides the fix-derived criterion. During Sibling Bug Validation, these three components guide the LLM-based validation of whether the historical failure pattern is present, whether the fix-derived criterion applies to the selected sibling, and whether the observed behavior violates the fix-derived oracle.

Fix One, Miss Another: Leveraging Historical Bug Fixes to Uncover Residual Bugs in Database Systems

6

19

Conclusion

In this paper, we identified sibling bugs, residual DBMS defects that persist in handlers corresponding to syntactic siblings after a localized fix. We presented Reaper, a fix-anchored DBMS fuzzing framework that reuses historical fixes to extend regression testing beyond the originally repaired path. Reaper recovers Trigger Profile and Validation Profile from historical fixes, projects bugtriggering queries to syntactic siblings defined by the SQL grammar, and validates sibling executions using fix-derived evidence. Evaluated on MariaDB, MySQL, OceanBase, and CockroachDB, Reaper uncovered 61 previously unknown bugs, of which 57 have been confirmed and 13 have been fixed by developers. These results show that historical fixes can serve as reusable testing knowledge for systematically exposing residual defects across handlers corresponding to syntactic siblings. 7

Data Availability

The source code and original evaluation data are hosted anonymously on Figshare: https://figshare. com/s/a9aab4d572fb108f7ba7. References [1] Jinsheng Ba and Manuel Rigger. 2023. Testing database engines via query plan guidance. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 2060–2071. [2] Yongheng Chen, Rui Zhong, Hong Hu, Hangfan Zhang, Yupeng Yang, Dinghao Wu, and Wenke Lee. 2021. One engine to fuzz’em all: Generic language processor testing with semantic validation. In 2021 IEEE Symposium on Security and Privacy (SP). IEEE, 642–658. [3] Cockroach Labs 2026. CockroachDB Documentation. Cockroach Labs. Accessed: 2026-10-01. https://www.cockroachlabs. com/docs/ [4] Ying Fu, Zhiyong Wu, Yuanliang Zhang, Jie Liang, Jingzhou Fu, Yu Jiang, Shanshan Li, and Xiangke Liao. 2025. Thanos: DBMS Bug Detection via Storage Engine Rotation Based Differential Testing. In 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). 655–666. doi:10.1109/ICSE55347.2025.00001 [5] Zongyin Hao, Quanfeng Huang, Chengpeng Wang, Jianfeng Wang, Yushan Zhang, Rongxin Wu, and Charles Zhang. 2023. Pinolo: Detecting logical bugs in database management systems with approximate query synthesis. In 2023 USENIX annual technical conference (USENIX ATC 23). 345–358. [6] ISO/IEC. 2016. Information Technology — Database Languages — SQL — Part 2: Foundation (SQL/Foundation). International Organization for Standardization, Geneva, Switzerland. [7] Zu-Ming Jiang, Jia-Ju Bai, and Zhendong Su. 2023. DynSQL: Stateful fuzzing for database management systems with complex and valid SQL query generation. In 32nd USENIX Security Symposium (USENIX Security 23). 4949–4965. [8] Zu-Ming Jiang and Zhendong Su. 2024. Detecting logic bugs in database engines via equivalent expression transformation. In 18th USENIX Symposium on operating systems design and implementation (OSDI 24). 821–835. [9] Jiaqi Li, Ke Wang, Yaoguang Chen, Yajin Zhou, Lei Wu, and Jiashui Wang. 2025. Detecting DBMS bugs with contextsensitive instantiation and multi-plan execution. Computers & Security 157 (2025), 104564. [10] Jie Liang, Zhiyong Wu, Jingzhou Fu, Mingzhe Wang, Chengnian Sun, and Yu Jiang. 2024. Mozi: Discovering dbms bugs via configuration-based equivalent transformation. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering. 1–12. [11] Yu Liang and Hong Hu. 2025. Parser Knows Best: Testing DBMS with Coverage-Guided Grammar-Rule Traversal. arXiv preprint arXiv:2503.03893 (2025). [12] Yu Liang and Peng Liu. 2026. Efficiently Detecting DBMS Bugs through Bottom-up Syntax-based SQL Generation. In NDSS. [13] Yu Liang, Song Liu, and Hong Hu. 2022. Detecting logical bugs of DBMS with coverage-based guidance. In 31st USENIX Security Symposium (USENIX Security 22). 4309–4326. [14] Li Lin, Liehang Chen, and Rongxin Wu. 2026. ValScope: Value-Semantics-Aware Metamorphic Testing for Detecting Logical Bugs in DBMSs. In 20th USENIX Symposium on Operating Systems Design and Implementation (OSDI 26). USENIX Association, Seattle, WA, 387–403. https://www.usenix.org/conference/osdi26/presentation/lin-li [15] Shuang Liu, Chenglin Tian, Jun Sun, Ruifeng Wang, Wei Lu, Yongxin Zhao, Yinxing Xue, Junjie Wang, and Xiaoyong Du. 2024. Semantic Conformance Testing of Relational DBMS. Proceedings of the VLDB Endowment 18, 3 (2024), 850–862. [16] Qiuyang Mang, Runyuan He, Suyang Zhong, Xiaoxuan Liu, Huanchen Zhang, and Alvin Cheung. 2026. Automated Discovery of Test Oracles for Database Management Systems Using LLMs. Proc. ACM Manag. Data 4, 3, Article 140 (May 2026), 28 pages. doi:10.1145/3802017

20

Yankai Rong, Zhaoyang Zhang, Shuang Liu, Wei Lu, and Xiaoyong Du

[17] MariaDB Corporation 2026. MariaDB Documentation. MariaDB Corporation. Accessed: 2026-10-01. https://mariadb. com/kb/en/ [18] Andreas Neumann. 2026. SQLSmith: Random SQL Query Generator for Testing DBMS. https://github.com/anse1/ sqlsmith. Accessed: 2026-05-19. [19] OceanBase 2026. OceanBase Documentation. OceanBase. Accessed: 2026-10-01. https://www.oceanbase.com/docs [20] Oracle Corporation 2026. MySQL 8.4 Reference Manual. Oracle Corporation. Accessed: 2026-10-01. https://dev.mysql. com/doc/refman/8.4/en/ [21] Mark Raasveldt and Hannes Mühleisen. 2019. Duckdb: an embeddable analytical database. In Proceedings of the 2019 international conference on management of data. 1981–1984. [22] Manuel Rigger and Zhendong Su. 2020. Detecting optimization bugs in database engines via non-optimizing reference engine construction. In Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering. 1140–1152. [23] Manuel Rigger and Zhendong Su. 2020. Finding bugs in database systems via query partitioning. Proceedings of the ACM on Programming Languages 4, OOPSLA (2020), 1–30. [24] Manuel Rigger and Zhendong Su. 2020. Testing database engines via pivoted query synthesis. In 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20). 667–682. [25] Yankai Rong, Shuang Liu, Jinhao Dong, Qiang Yin, Wei Lu, Jianhua Wang, and Xiaoyong Du. 2026. DBcover: A White-box SQL Test Generation Framework for Coverage Improvement. In Proceedings of the 2026 IEEE/ACM 48th International Conference on Software Engineering (ICSE-Companion ’26). Association for Computing Machinery, New York, NY, USA, 367–378. doi:10.1145/3774748.3793626 [26] Jiansen Song, Wensheng Dou, Ziyu Cui, Qianwang Dai, Wei Wang, Jun Wei, Hua Zhong, and Tao Huang. 2023. Testing database systems via differential query execution. In 2023 IEEE/ACM 45th International conference on software engineering (ICSE). IEEE, 2072–2084. [27] Jin Wei, Ping Chen, Kangjie Lu, Jun Dai, and Xiaoyan Sun. 2026. SQLaser: Detecting database management system (DBMS) logic bugs with clause-guided fuzzing. Journal of Computer Security 34, 1 (2026), 3–28. [28] Chi Zhang and Manuel Rigger. 2025. Constant optimization driven database system testing. Proceedings of the ACM on Management of Data 3, 1 (2025), 1–24. [29] Rui Zhong, Yongheng Chen, Hong Hu, Hangfan Zhang, Wenke Lee, and Dinghao Wu. 2020. Squirrel: Testing database management systems with language validity and coverage feedback. In Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security. 955–970. [30] Suyang Zhong and Manuel Rigger. 2025. Testing Database Systems with Large Language Model Synthesized Fragments. arXiv preprint arXiv:2505.02012 (2025). [31] Suyang Zhong and Manuel Rigger. 2026. Scaling Automated Database System Testing. In Proceedings of the 31st ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2. 1677–1692.

Related documents

• Post-SQLFix: Property-Guided Repair of LLM-Generated SQL with Runtime Verification#1534647
• SynQL: A Controllable and Scalable Rule-Based Framework for SQL Workload Synthesis for Performance Benchmarking#2750
• Antaeus: Hunting Repository-Level Logic Vulnerabilities via Context-Grounded LLM Reasoning#820541
• PV-SQL: Synergizing Database Probing and Rule-based Verification for Text-to-SQL Agents#120623
• Prompt as a Data Type: In-Database LLM Prompt Management and Rewriting#411179