Skip to content

docs(transactions): note the lost-update risk in read-modify-write - #4593

Open
shaikn6 wants to merge 1 commit into
sqlc-dev:mainfrom
shaikn6:docs/transactions-concurrent-read-modify-write
Open

docs(transactions): note the lost-update risk in read-modify-write#4593
shaikn6 wants to merge 1 commit into
sqlc-dev:mainfrom
shaikn6:docs/transactions-concurrent-read-modify-write

Conversation

@shaikn6

@shaikn6 shaikn6 commented Aug 28, 2026

Copy link
Copy Markdown

What

The Using transactions how-to's bumpCounter example reads a row and then writes counter + 1 inside a transaction:

r, err := qtx.GetRecord(ctx, id)
...
qtx.UpdateRecord(ctx, tutorial.UpdateRecordParams{ID: r.ID, Counter: r.Counter + 1})

Under the default isolation level (READ COMMITTED, on both PostgreSQL and MySQL/InnoDB), two transactions running this concurrently can both read the same counter and both write the same counter + 1 — a lost update. The page presents this as the standard pattern with no caveat, which is what #3485 flags.

Change

Docs only. Adds a short Concurrent read-modify-write section after the examples:

  • explains the lost-update window
  • shows a GetRecordForUpdate query using SELECT ... FOR UPDATE
  • mentions SERIALIZABLE + retry as the alternative, noting sqlc doesn't manage isolation levels or retries

Existing examples are unchanged — they still demonstrate WithTx, which is the page's purpose.

Closes #3485

The bumpCounter example reads a row and writes counter+1 in a transaction
without locking. Under READ COMMITTED (the default) two concurrent runs can
both read the same value and lose an update. Add a short section pointing at
SELECT ... FOR UPDATE and SERIALIZABLE + retry.

Addresses sqlc-dev#3485
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

1 participant