Transactions, locking and roles
Transactions make multi-step changes atomic; roles limit what can happen.
What you will be able to do
- Keep transactions short to avoid lock contention.
- Set an explicit isolation level when correctness depends on it.
- Use row-level security for user-scoped data in shared tables.
In plain English
BEGIN and COMMIT group work; a failure rolls back. Isolation levels trade consistency for concurrency. Use least-privilege roles, row-level security for multi-tenant data, and never connect the application as a superuser.
begin;
update courses set published = true where slug = 'postgresql';
insert into audit_events (action, object_id)
values ('course.published', 'postgresql');
commit;
create role app_reader nologin;
grant select on courses, lessons to app_reader;
alter table lesson_progress enable row level security;Your turn
MediumMake an atomic publication change
Group a course update and an audit insert in one transaction.
SQL · starter
update courses set published = true where slug = 'postgresql';Check your understanding before moving on.
Knowledge checkQuestion 1
What happens to a transaction after an error before COMMIT?
Select an answer to continue
Study tools
Make it yours.
Keep a private note for this lesson, then turn the key ideas into flashcards you can revisit.
Sign in to save notes and flashcards.Both are private to your account and stay with your progress.
Sign inFinished reading?
Lock in what you just learned.
0%
Mark this lesson complete to save your place and move one step closer to the certificate.