On page 52 of PostgreSQL 14 Internals, Egor Rogov indicates that "lost updates" can occur with the "Read Committed" isolation level. There is also a sentence that reads:
But in some cases, there is a risk of losing changes at the
Read Committedlevel.
I would like to understand what one of the (special?) cases is. Under what circumstance does this anomaly happen?
Short answer is there's no such case.
The special case the author has in mind isn't one where Postgres can lose an update, it's where the larger system Postgres is a part of, appears to lose an update. The case in question requires users in concurrent transactions to re-use values read previously, disregarding the fact that between the initial read and its re-use, someone's commit might have rendered the value outdated.
Thing is, if you want to do things that way, you're supposed to use
repeatable readmode and/orselect for update(or another explicit lock), locking the rows you plan to update.In the PDF version the quote you refer to is on page 44. Page 52 describes said case of lost update: