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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Error in the documentation for transactions?

1 participant