All Topics
All Topics
Technology
Technology
AI
AI
Business
Business
Entertainment
Entertainment
News
News
Programming
Programming
Security
Security
Science
Science
Design
Design
Environment
Environment
Finance
Finance
Crypto
Crypto
Politics
Politics
Sports
Sports
Education
Education
Gaming
Gaming
Art
Art
Music
Music
Health
Health
Books
Books
Food
Food
Travel
Travel
Personal
Personal
Bluesky
Twitter

D1, Workers - D1 automatically retries read-only queries

9mo ago

Source

CloudflareD1, Workers - D1 automatically retries read-only queriescloudflare.com
Snippet from the RSS feed
D1 now detects read-only queries and automatically attempts up to two retries to execute those queries in the event of failures with retryable errors. You can access the number of execution attempts in the returned response metadata property total_attempts . At the moment, only read-only queries are retried, that is, queries containing only the following SQLite keywords: SELECT , EXPLAIN , WITH . Queries containing any SQLite keyword that leads to database writes are not retried. The retry success ratio among read-only retryable errors varies from 5% all the way up to 95%, depending on the underlying error and its duration (like network errors or other internal errors). The retry success ratio among all retryable errors is lower, indicating that there are write-queries that could be retried. Therefore, we recommend D1 users to continue applying retries in their own code for queries that are not read-only but are idempotent according to the business logic of the application. D1 ensures that any retry attempt does not cause database writes, making the automatic retries safe from side-effects, even if a query causing changes slips through the read-only detection. D1 achieves this by checking for modifications after every query execution, and if any write occurred due to a retry attempt, the query is rolled back. The read-only query detection heuristics are simple for now, and there is room for improvement to capture more cases of queries that can be retried, so this is just the beginning.

You might also wanna read

Debugging a slow password reset query in CockroachDB: from 700k rows to 10

A software engineer recounts investigating a slow password reset query flagged by their CTO. The query was reading 700k rows instead of the

gaultier.github.io·4d ago

Implementing a Durable Execution Engine Using SQLite for Persistent Workflows

The article explores building a Durable Execution (DE) engine using SQLite, explaining how DE engines make multi-step workflows persistent a

morling.dev·7mo ago

Comparing Transaction Isolation Levels in MySQL and MariaDB Through Automated Hermitage Testing

This article discusses transaction isolation levels (Read Uncommitted, Read Committed, Repeatable Read, Serializable) in MySQL and MariaDB,

theconsensus.dev·1mo ago

SQLite Query Optimization: Using Uncorrelated Subqueries to Skip Correlated Subqueries for Performance Gains

The article describes a SQLite query optimization technique where an uncorrelated scalar subquery is used to skip expensive correlated subqu

emschwartz.me·6mo ago

The performance cost of random UUID primary keys in SQLite and clustered indexes

This article examines the performance drawbacks of using random UUIDs (specifically UUID4) as primary keys in SQLite databases. It explains

andersmurphy.com·29d ago

Check Point Researchers Chain SQL Injection in LangGraph AI Agent Memory to Achieve Remote Code Execution

This article details a security research finding where Check Point researchers discovered and chained a SQL injection vulnerability in LangG

undercodetesting.com·12d ago

Comments

Sign in to join the conversation.

No comments yet. Be the first.