mirror of
https://github.com/aljazceru/turso.git
synced 2025-12-30 06:24:21 +01:00
54ff656c9d
If a connection does e.g. CREATE TABLE, it will start a "child statement" to reparse the schema. That statement does not start its own transaction, and so should not try to end the existing one either. We had a logic bug where these steps would happen: - `CREATE TABLE` executed successfully - pread fault happens inside `ParseSchema` child stmt - `handle_program_error()` is called - `pager.end_tx()` returns immediately because `is_nested_stmt` is true and we correctly no-op it. - however, crucially: `handle_program_error()` then sets tx state to None - parent statement now catches error from nested stmt and calls `handle_program_error()`, which calls `pager.end_tx()` again, and since txn state is None, when it calls `rollback()` we panic on the assertion `"dirty pages should be empty for read txn"` Solution: Do not do _any_ error processing in `handle_program_error()` inside a nested stmt. This means that the parent write txn is still active when it processes the error from the child and we avoid this panic.