# What Fekete's Anomaly Can Teach Us About Isolation

DevFeed: [What Fekete's Anomaly Can Teach Us About Isolation](<https://devfeed.tech/articles/what-fekete-s-anomaly-can-teach-us-about-isolation-12569.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2025/02/05/feketes.html>)

Author: Marc Brooker

Published: 2025-02-05T00:00:00Z

Content type: article

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [Transactions](<https://devfeed.tech/topics/transactions.md>), [Databases](<https://devfeed.tech/topics/databases.md>), [SQL](<https://devfeed.tech/topics/sql.md>)

Tags: [database](<https://devfeed.tech/tags/database.md>), [sql](<https://devfeed.tech/tags/sql.md>), [transactions](<https://devfeed.tech/tags/transactions.md>)

## AI overview

The article explains Fekete's anomaly, a read-only transaction anomaly associated with snapshot isolation. It uses a bank-account example and SQL transactions to show how weaker-than-serializable isolation can produce an unexpected result, while serializable isolation would reject at least one transaction.

## Source excerpt

What Fekete's Anomaly Can Teach Us About Isolation Is it just fancy write skew? In the first draft of yesterday's post, the example I used was one that showed Fekete's anomaly. After drafting, I realized the example distracted too much from the story. But there's still something I want to say about the anomaly, and so now we're here. What is Fekete's anomaly? It's an example of a snapshot isolation behavior first described in Fekete, O'Neil, and O'Neil's paper A Read-Only Transaction Anomaly Under Snapshot Isolation. The first time I read about it, I found it spooky. As in five stages of grief spooky. But the more I've thought about it, the more I think it's just a great teaching example. To understand the anomaly, let's talk about two people. We'll call the Pat and Betty. Pat and Betty share a pair of bank accounts - a savings account and a current account. They bank at Alan's bank, which charges a $1 overdraft fee any time a withdrawal will reduce the total value of their accounts below $0. One day, Pat and Betty are running separate errands. Pat goes to the ATM, checks the savings balance and sees $0, then deposits $20. After completing his transaction, Pat comes back to the ATM, checks their balance, and sees $20 in savings, and $0 in current. Around the same time, Betty goes to the ATM and withdraws $10 from the current account. Checking their account later, they notice a balance of -$11 in the current account, and $20 in savings. But that's impossible! Pat saw $0 and $20, so Alan's bank shouldn't have charged them that $1. Did they get ripped off? In SQL Let's tell the same story again, in SQL. Starting with some setup: begin; -- T0 create table test (id int primary key, balance int); -- T0 insert into test (id, value) values (0, 0), (1, 0); -- T0 commit; -- T0 Then we get to the anomaly itself, showing Pat's two transactions (P1 and P2), and Betty's one (B1): begin; -- P1 begin; -- B1 select balance from test where id in (0, 1); -- B1 select balance from test