[Solved] Consider two transactions running concurrently under Read Committed isolation. Transaction 1 updates a row but has not committed yet. Transaction 2 tries to read that same row.... | PostgreSQL

PostgreSQL - Transactions and Concurrency

Consider two transactions running concurrently under Read Committed isolation. Transaction 1 updates a row but has not committed yet. Transaction 2 tries to read that same row. What will Transaction 2 see?

AThe original data before Transaction 1's update.

BThe updated but uncommitted data from Transaction 1.

CAn error due to concurrent update conflict.

DNo data, the row is locked and invisible.

Step-by-Step Solution

Solution:

Step 1: Understand Read Committed behavior on concurrent reads
Under Read Committed, a transaction sees only committed data. Uncommitted changes from other transactions are invisible.
Step 2: Apply to scenario
Transaction 1's update is uncommitted, so Transaction 2 reads the original committed data before the update.
Final Answer:
The original data before Transaction 1's update. -> Option A
Quick Check:
Read Committed hides uncommitted changes [OK]

Quick Trick: Uncommitted changes are invisible under Read Committed [OK]

Common Mistakes:

Assuming dirty reads are allowed
Thinking a read error occurs
Believing the row is locked and unreadable

Master "Transactions and Concurrency" in PostgreSQL

9 interactive learning modes - each teaches the same concept differently

Learn Why Deep Visual Try Challenge Project Recall Time

What will Transaction 2 see?

Step 1: Understand Read Committed behavior on concurrent reads

Step 2: Apply to scenario

Final Answer:

Quick Check:

Want More Practice?